PONTIFCIA UNIVERSIDADE CATLICA DO PARAN CENTRO DE CINCIAS EXATAS E DE TECNOLOGIA CURSO DE PS GRADUAO EM TECNOLOGIAS PARA SISTEMAS DE INFORMAO

ENIO PERPTUO JNIOR IVERSON LOURENO JAGIELLO

WEB SERVICES UMA SOLUO PARA APLICAES DISTRIBUDAS NA INTERNET

CURITIBA 2003

ENIO PERPTUO JNIOR IVERSON LOURENO JAGIELLO

WEB SERVICES UMA SOLUO PARA APLICAES DISTRIBUDAS NA INTERNET

Monografia graduao

apresentada em

pspara

Tecnologias

Sistemas de Informao da Pontifcia Universidade Catlica do Paran, sob a orientao do Professor Edgard Jamhour.

Orientador:____________________

CURITIBA 2003

ENIO PERPTUO JNIOR IVERSON LOURENO JAGIELLO

WEB SERVICES UMA SOLUO PARA APLICAES DISTRIBUDAS NA INTERNET

Monografia apresentada ps-graduao em Tecnologias para Sistemas de Informao da Pontifcia Universidade Catlica do Paran, sob a orientao do Professor Edgard Jamhour.

Orientador:_________________________________
Prof. Dr. Edgard Jamhour

__________________________________

__________________________________

Na prtica, as mquinas do amanh no sero puras mquinas de rede que adquirem suas funes on-line nem puros PCs, recheados de softwares de fbrica. Eles usaro uma mistura de recursos locais e remotos por meio de softwares nmades, 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 revoluo na comunicao entre aplicaes: os Web Services. Alguns dos aspectos da tecnologia de Web Services nos despertam muita ateno porque, em primeiro lugar, eles so 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 padres que definem como sistemas diferentes devem interagir entre si, num nvel at ento improvvel de cooperao entre concorrentes. Alm disso, a abordagem de Web Services no torna necessariamente as tecnologias de integrao anteriores obsoletas, mas viabiliza tipos de integrao anteriormente muito complexos. Palavras-chave: Web Services - Internet XML - Aplicaes Distribudas - B2B - Segurana

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 Services technology 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

Sumrio

Sumrio...................................................................................................................................... 7 I - Introduo ............................................................................................................................ 9 Estrutura do trabalho ......................................................................................................... 10 II - A Evoluo dos Sistemas Distribudos ........................................................................... 11 Arquitetura Cliente / Servidor ............................................................................................ 11 Arquitetura Orientada a Objetos ........................................................................................ 12 Internet / Intranet................................................................................................................ 13 Arquiteturas Distribudas Orientadas a Objetos................................................................ 14 CORBA x DCOM.......................................................................................................... 14 J2EE x .NET ................................................................................................................. 15 Web Services ....................................................................................................................... 16 III - Arquitetura...................................................................................................................... 17 Componentes (components)................................................................................................ 20 Papis (funes) Roles..................................................................................................... 20 Operaes 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 Pginas Brancas (White Pages) ................................................................................... 40 Pginas Amarelas (Yellow Pages) ............................................................................... 40 Pginas Verdes (Green Pages)..................................................................................... 41 Arquitetura UDDI......................................................................................................... 41 Sites-Operadores .......................................................................................................... 42 Registrars ..................................................................................................................... 42 V - Segurana .......................................................................................................................... 43 Segurana ao nvel de Transporte ...................................................................................... 44 SSL ................................................................................................................................ 44 PKI................................................................................................................................ 44 IPSec............................................................................................................................. 45 Segurana ao nvel de XML................................................................................................ 47 XKMS (XML Key Management Services)..................................................................... 48 WS-Security .................................................................................................................. 48 VI - Aplicao de WS em B2B............................................................................................... 50 Vantagens e Desvantagens do WS ...................................................................................... 52 VII - Como o Mercado apoia o padro................................................................................. 54 Microsoft....................................................................................................................... 54 Sun Microsystems ......................................................................................................... 54 Oracle ........................................................................................................................... 55 META Group ................................................................................................................ 55 OASIS............................................................................................................................ 55 TechMetrix Research.................................................................................................... 56 Forrester Research Inc................................................................................................. 56 VIII Concluso..................................................................................................................... 57 Referncias .............................................................................................................................. 58

I - Introduo

Durante o curso de especializao, tivemos contato com as principais tecnologias de sistemas de informao e acompanhamos o sua evoluo impulsionada, entre outros motivos, pela enorme necessidade de integrao 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 revoluo nas comunicaes entre as aplicaes: os Web Services. Alguns dos aspectos da tecnologia de Web Services nos despertam muita ateno porque, em primeiro lugar, eles so 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 padres que definem como sistemas diferentes devem interagir entre si, num nvel at ento improvvel de cooperao entre concorrentes. Alm disso, a abordagem de Web Services no torna necessariamente as tecnologias de integrao anteriores obsoletas, mas viabiliza tipos de integrao 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 tendncia de desenvolvimento de software proposto por ela. A fim de obter informaes 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 endereos acessados encontram-se listados ao final deste trabalho onde informaes ainda mais aprofundadas podem ser obtidas.

10

Estrutura do trabalho No captulo seguinte descrito de maneira breve a evoluo dos sistemas computacionais distribudos desde a arquitetura centralizada, Client-Server, Aplicaes Distribudas, Objetos Distribudos, o surgimento de aplicaes para a Internet at a necessidade de se obter uma interoperabilidade entre estas aplicaes nos dias atuais. O captulo III descreve mais detalhadamente o conceito de Web Services e apresenta a sua Arquitetura e elementos. No captulo IV sero apresentados os principais protocolos utilizados em Web Services, tais como SOAP, UDDI, WSDL pretendendo assim mostrar como estes protocolos se encaixam para formar a base desta nova arquitetura. O captulo V dedica-se a rever alguns dos principais protocolos de segurana desenvolvidos para suportar as aplicaes distribudas e mostrar como eles podem ser aplicados para garantir transaes seguras em Web Services. Alm de citar os novos protocolos especialmente desenvolvidos para este fim. O sexto captulo deste trabalho apresenta como a arquitetura de Web Services se encaixa neste novo contexto de aplicaes distribudas e B2B alm de apresentar quais os benefcios que ela traz tanto aos desenvolvedores quanto para os usurios. Neste captulo tambm, ser apresentado quais as situaes em que a aplicao de Web Services no a mais adequada. No captulo VII apresentamos as aes de algumas das principais empresas envolvidas na padronizao da Arquitetura de Web Services, quais as tendncias em relao movimentao do mercado em torno do Web Services e algumas pesquisas que apontam o que est previsto para os prximos anos.

II - A Evoluo dos Sistemas Distribudos

Arquitetura Cliente / Servidor No incio da dcada de 90, a grande novidade nos sistemas corporativos era a arquitetura cliente/servidor, expresso que designa um tipo de arquitetura de sistemas que se contraps 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 no possuam nenhuma capacidade de processamento ou armazenamento de dados local, caracterizando um sistema extremamente inflexvel. Com o adventos das LANs (Local Area Network) a situao comeou a melhorar. Os arquivos e programas mais importantes passaram a residir num servidor de arquivos, protegidos por senhas e backups automticos. O gerenciamento das impressoras passou a ser tambm centralizado, otimizando sua utilizao. Todo o processamento ainda se concentrava na prpria estao de trabalho do usurio. Entretanto, os sistemas baseados em bancos de dados, espinha dorsal da maioria das empresas, continuavam a residir nos Mainframes, com interfaces no-amigveis. Para integrar os sistemas de bancos de dados aos microcomputadores que tornavam-se cada vez mais comuns nas mesas dos usurios, comeou a ser difundido o conceito de arquitetura cliente/servidor. A grande novidade desta arquitetura a separao dos aplicativos corporativos e do processamento de transaes em duas partes, uma executada no servidor e outra na mquina do cliente. Nesses aplicativos distribudos, a poro servidor responsvel pela segurana e pela integridade dos dados, enquanto o cliente serve para exibir os dados

12

numa interface amigvel e de modo personalizvel ao usurio final. Este modelo, embora amplamente difundido, possui um alto custo de suporte e manuteno.

Arquitetura Orientada a Objetos Na programao distribuda usando a arquitetura cliente-servidor, clientes e servidores podem ser implementados usando qualquer paradigma de programao. Assim, possvel que um servio especfico seja executado por um mtodo de algum objeto. No entanto, mesmo que o cliente tambm tenha sido desenvolvido orientao a objetos, na comunicao entre o cliente e o servidor esse paradigma deve ser esquecido, devendo ser utilizado algum protocolo preestabelecido de troca de mensagens para a solicitao e resposta ao servio. Um sistema de objetos distribudos aquele que permite a operao com objetos remotos. Dessa forma possvel, a partir de uma aplicao cliente orientada a objetos, obter uma referncia para um objeto que oferece o servio desejado e, atravs dessa referncia, invocar mtodos desse objeto, mesmo que a instncia desse objeto esteja em uma mquina diferente daquela do objeto cliente. O conceito bsico que suporta plataformas de objetos distribudos o conceito de arquiteturas de objetos. Essencialmente, uma arquitetura orientada a objetos estabelece as regras, diretrizes e convenes definindo como as aplicaes podem se comunicar e interoperar. Dessa forma, o foco da arquitetura no em como a implementao realizada, mas sim na infra-estrutura e na interface entre os componentes da arquitetura. No paradigma de arquiteturas de objetos, h trs elementos principais. A arquitetura OO fornece uma descrio abstrata do software, que categorias de objetos sero utilizadas, como estaro particionados e como interagiro. As interfaces so as descries detalhadas das funcionalidades do software. Finalmente, a implementao composta por mdulos de software que suportam as funcionalidades especificadas nas interfaces. O uso de interfaces permite isolar a arquitetura de um sistema de sua implementao. Dessa forma, o sistema pode ser construdo com um alto grau de independncia em relao s implementaes especficas de suas funcionalidades, ou seja, possvel substituir implementaes especficas com pequeno impacto sobre o sistema como um todo.

13

A adoo do paradigma de arquitetura de objetos permite tambm atingir um alto grau de interoperabilidade atravs da adoo de uma infra-estrutura padronizada de comunicao entre objetos atravs das interfaces. Assim, cada componente da arquitetura deve se preocupar apenas em como se dar sua comunicao com a infra-estrutura de comunicao.

Internet / Intranet A partir de 1994, o fenmeno da Web mostrou um novo modelo de integrao de sistemas, constituindo-se de padres abertos, com maior independncia em relao aos fornecedores, trazendo um novo enfoque para a relao cliente/servidor. Por meio de formulrios desenvolvidos em linguagem HTML (Hypertext Markup Language), clientes e servidores podem trocar informaes, pode-se ter acesso a bancos de dados, documentos ficam a disposio de usurios 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 corporaes, por meio de uma verso domstica da Internet, a Intranet, tecnologia que vem varrendo o mundo empresarial. Embora a Intranet ainda apresente limitaes no desenvolvimento de aplicaes que acessem bancos de dados no estilo do modelo cliente/servidor, seu baixo custo e facilidade de implantao vm fazendo com que cada vez mais empresas adotem esta tecnologia. Nos ltimos anos diversos padres foram propostos para a implementao do conceito de sistemas distribudos. Um modelo muito popular tem sido o de separao de uma aplicao em camadas, apresentao, negcio e dados. No entanto, ainda nos deparamos com alguns problemas que impedem que este modelo desenvolva-se plenamente, tais como: complexidade de implementao e, principalmente, implantao. Sistemas escritos em diferentes linguagens, e no raro em plataformas distintas, sofrem ainda de um mal bem mais grave, a incompatibilidade entre os tipos de dados, alm da necessidade de forte envolvimento das equipes tcnicas de ambos os lados no processo de integrao. Estas tem sido as principais causas da baixa integrao entre os sistemas de clientes e fornecedores mesmo com toda a facilidade de infra-estrutura de comunicao existente hoje em dia.

14

Arquiteturas Distribudas Orientadas a Objetos A necessidade de integrao das aplicaes que se encontravam em ambientes heterogneos e a necessidade de comunicao entre elas em tempo-real fez com que a computao distribuda ganhasse cada vez mais espao no mundo atual. O DCE (Distributed Computer Environment) foi o comeo dessa tendncia de computao distribuda em empresas, porm o DCE no era orientado a objeto, assim surgiu o CORBA, que uma arquitetura de objetos para computao distribuda. e junto com o CORBA veio o DCOM da Microsoft. O DCOM era o principal concorrente do CORBA, a diferena entre essas duas tecnologias que o CORBA roda em multiplataforma, enquanto o DCOM s em ambientes Windows.

CORBA x DCOM O padro CORBA (Common Object Request Broker Architecture), um conjunto de especificaes criado pela OMG (Object Management Group), um grupo formado por mais de 800 empresas da indstria de informtica. Um sistema baseado em CORBA composto por objetos distribudos, que so elementos de software que implementam um determinado processamento e possuem uma determinada interface. O CORBA define uma camada intermediria (middleware) entre os objetos distribudos da aplicao e a rede de comunicao. A localizao do objeto e a linguagem na qual ele est implementado so mantidos totalmente transparentes. Detalhes de implementao e localizao no precisam ser conhecidos para se fazer uma requisio a um objeto. Tudo que necessrio saber de um objeto CORBA para requisit-los, a sua interface. A interface de um objeto definida atravs da linguagem IDL (Interface Definition Language), que totalmente declarativa, no trazendo nenhum detalhe de implementao de objeto. A linguagem IDL permite definir os mtodos e atributos de um objeto e excees que ele pode gerar. Ela permite a independncia de sistema operacional e de linguagem de programao 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 evoluo natural do OLE/COM ( Object Linking Embedding/Component Object Model), lanado em 1993 com o objetivo de suportar a comunicao entre objetos distribudos. O DCOM faz uso dos

15

investimentos realizados no COM, tais como aplicaes, componentes, ferramentas e conhecimento para ingressar no mundo da computao distribuda baseado nas padronizaes j existentes. Trata-se de um protocolo que possibilita componentes de software se comunicarem diretamente sobre uma rede de maneira confivel. O COM define como deve ser a interao entre os objetos e seus clientes, sem a intermediao de qualquer componente do sistema. Analogamente s DLLs, que so cdigos compilados prontos para uso, o modelo de componentes do DCOM seria uma verso orientada a objeto da DLL, com poderes ampliados tais como a reutilizao de cdigo.

J2EE x .NET Com o J2EE (Java 2 Entreprise Edition) e a plataforma .NET, Sun Microsystems e Microsoft, respectivamente, travam um novo duelo de tits na competitiva arena de desenvolvimento de aplicaes para Internet. Com a .NET, a Microsoft introduziu uma plataforma capaz de competir em iguais condies com a J2EE (Java 2 Platform, Enterprise Edition), da Sun Microsystems. Java representa mais do que uma linguagem de programao, pois, ao lado da tecnologia de mquinas virtuais (JVM), permite compilar os programas, sem alteraes, para serem executados em diversos equipamentos. A plataforma da Microsoft era, at pouco tempo atrs, essencialmente baseada no Windows e estava atrelada ao mundo do PC. Com o advento da .NET, a primeira grande diferena que o ambiente de desenvolvimento agora ampliou sua atuao tambm para outros dispositivos e para acrescentar a contribuio de ferramentas de parceiros. Por outro lado, Mais do que uma plataforma de desenvolvimento de aplicaes, a Sun Microsystems acena para o mercado com uma opo que segue o ideal de se trabalhar com solues 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 so compatveis com os principais padres 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 integrao entre sistemas heterogneos, de forma bastante flexvel, substituindo as tradicionais estratgias de EAI. O significado de Enterprise Application Integration (EAI), cuja traduo seria Integrao de Aplicaes Corporativas, mudou com o tempo. H algum tempo, o termo era exclusivamente usado para designar a tentativa de uma empresa de interligar suas aplicaes internas de negcios de forma que os dados possam ser compartilhados entre elas. Recentemente, o significado foi expandido para tambm englobar a unio de dados e processos com parceiros comerciais externos. No raro que o ambiente de tecnologia seja bastante heterogneo dentro de uma mesma empresa, com sistemas distintos para cada aplicao. Novas tecnologias e frameworks de desenvolvimento esto surgindo, tendo como objetivo uma maior integrao entre os diversos aplicativos e servios disponveis na Internet. Este novo modelo em crescimento deve tratar tarefas complexas, como o gerenciamento de transaes, atravs da disponibilizao de servios distribudos que utilizem interfaces de acesso simples e bem definidas. Web Services permitem a integrao entre sistemas distintos de forma bastante simples e direta. Uma das regras que nortearam a criao do padro foi "no invente nada de novo". Basicamente um Web service funciona como uma pgina Web, com a diferena que ao invs 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 relao, vrios componentes e tecnologias que compreendem uma pilha de Web services ou implementaes completamente funcionais. Componentes e tecnologias que estendem a arquitetura bsica so representadas dentro da arquitetura estendida. A arquitetura bsica inclui tecnologias Web services capazes de: trocar mensagens; descrever Web services; publicar e descobrir descries Web services.

O fundamento da arquitetura Web services define uma interao entre agentes de software como um trocador de mensagens entre servios requisitados e provedores de servio. Os requisitantes so softwares agentes que requisitam a execuo do servio. Provedores so agentes de software que provem um servio. Agentes podem ser ambos, requisitantes e provedores. Provedores so responsveis por publicar a descrio do servio que ele esta disponibilizando / provendo. Requisitantes devem ser capazes de encontrar as descries dos servios. O fundamento dos modelos de arquitetura do Web service interagem entre agentes realizando qualquer das trs funes: provedor de servio, agncia de servio de publicao e requisio do servio. A interao envolve a publicao, localizao e operao de unio. Num cenrio tpico um provedor de servio hospeda um exemplo de uma rede acessvel atravs de agente de software. O provedor do servio define a descrio do servio para o Web service e publica isso para um requisitante ou para um agente de publicao. O requisitante do servio usa uma funo de procura para recuperar a localizao do servio

18

localmente ou para descobrir uma agncia de publicao (ex: registro ou repositrio) e usa o servio de descrio para ligar o Web service com o provedor e invocar ou interagir com a implementao do Web service. O provedor de servio e a funo de requisitante so

desenvolvidas e um servio deve exibir caractersticas de ambas. O uso de Web services na Internet esta se expandindo rapidamente como uma necessidade por comunicao de aplicativo pra aplicativo e crescente interoperabilidade. A excitao encima do Web service baseada no potencial para uma combinao de especificaes de XML, a Internet, o SOAP e o WSDL, e na definio de protocolos de endereamento 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 esto agora sendo desenvolvidos dentro das atividades do Web service W3C. Estas especificaes esto sendo usadas como a base para a criao de uma arquitetura de mensagens extensvel (SOAP 1.2) e a definio de uma interface de linguagem (WSDL 1.2).

A figura acima ilustra a arquitetura bsica do Web service, na qual um requisitante de servio e um provedor interagem baseados no servio descrio da informao publicada pelo provedor e descoberta pelo requisitante atravs de algumas formas de descobrimento da agencia. O servio requisitado e os provedores interagem trocando mensagens, as quais devem ser agregadas para o formulrio MEPs message Exchange patterns (padres de troca de mensagens).

19

No desenho acima, os ns do tringulo representam as funes ou papeis, e as extremidades representam as operaes. Um ou mais mediadores devem existir no caminho entre um requisitante e um provedor. Mediadores, onde presentes, no podem interferir com o MEP. Mediadores devem realizar certas funes associadas com a mensagem assim como rotinas, segurana, gerenciamento, ou outras operaes. Exemplos de MEPs incluem unilateralmente, requisies/respostas, publicao/aprovao, e transmisso. Arquitetura de componentes bsica de Web Service so tipicamente definidas usando aplicaes XML, usando definies XML tipos de mensagens e estruturao, e usando para transporte o http. Componentes de arquitetura estendida em Web services so tipicamente definidas usando extenses para conduzir aplicaes XML e transport-la, incluindo alternativas para o http. Uma mensagem definida como uma combinao que pode incluir zeros ou mais cabealhos em adio para dados. A parte do cabealho de uma mensagem pode incluir informao pertinente para estender as funcionalidades, como segurana, contextos de transao, informao de orquestrao, ou informao para roteamento de mensagens. O dado da parte da mensagem contm um contedo de mensagem ou dados. Um Web service descrito usando um padro, uma notao formal XML, chama-se isso de descrio do servio, que prov todos os detalhes necessrios para interagir com o servio, incluindo formato de mensagens, transporte de protocolos, e localizao. As naturezas das interfaces escondem os detalhes da implementao do servio ento 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 agregao complexa ou uma transao de negcios. A figura acima ilustra a relao entre requisitantes, provedores, servios, descries, e descobridores de servio no caso, agentes onde agentes fazem o papel de requisitantes e provedores. O provedor de publicao um arquivo WSDL que contm a descrio da mensagem e ponto final da informao para permitir ao requisitante gerar a mensagem SOAP e envi-la para o destino correto.

20

Para

implantar

um

MEP

comum

(padro

de

troca

de

mensagens)

da

requisio/resposta, por exemplo, uma implementao Web service prove agentes de software que funcionam ao mesmo tempo como requisitantes e provedores. O requisitante do servio envia uma mensagem em forma de uma requisio de informao, ou para realizar uma operao, e receber uma mensagem do provedor do servio que conter um resultado para a requisio ou operao. O provedor do servio recebe a requisio, processa a mensagem e envia uma resposta. A tecnologia tipicamente usada para esse tipo de interao Web service inclui SOAP, WSDL, e http. As seguintes sees provem mais definies para os componentes, funes, e operaes na arquitetura Web service. Componentes (components) Servio: considerando que um Web service uma interface descrita por uma descrio de servio, esta implementao o servio. Um servio um modulo de software desenvolvido em plataformas de rede acessveis providos por provedores de servio. E existe para ser chamado ou interagir com um requisitante do servio. Isto deve ser funcional tambm como um requisitante, usando outros Web services nessa implementao. Descrio do servio: As descries do servio contem detalhes da interface e implementao do servio. Isso inclui seus tipos de dados, operaes, informaes de ligaes, e localizao de rede, poderiam tambm incluir categorizao e outros meta dados para descobrir facilidades e utilizao pelos requisitantes. A descrio completa deve ser realizada como um conjunto de descries de documentos XML. A descrio do servio deve ser publicada para um requisitante diretamente ou para uma agencia descobridora. Papis (funes) Roles Provedor de servio: De uma perspectiva de servio, este o proprietrio do servio. De uma perspectiva de arquitetura a plataforma que hospeda o acesso para o servio. Tambm sendo referenciado como um ambiente de execuo do servio ou um compartimento do servio. Esse papel no padro de troca de mensagens aquele de um servidor. Requisitante do servio: de uma perspectiva de um negcio uma tarefa que requer certas funes para ser satisfeita. De uma perspectiva de arquitetura esse a aplicao que

21

esta olhando para uma invocao ou inicializando uma interao com um servio. O papel de requisitante pode ser feito por um browser dirigido para uma pessoa ou um programa sem uma interface de usurio. Agncia descobridora: Esta uma localizadora padro de descrio de servios onde os provedores do servio publicam suas descries de servio. O servio de agencia descobridora pode ser centralizada ou distribuda. A agencia descobridora pode suportar ambos os padres onde tenha que enviar descries e onde possa ativamente inspecionar, procurar por provedores de descries de servios. Requisitantes de servios devem localizar servios e obter ligaes de informaes durante o desenvolvimento de ligaes estticas, ou durante a execuo de ligaes dinmicas. Operaes Operations Para uma aplicao tomar vantagens do Web services, trs maneiras devem tomar lugar: publicao das descries dos servios, localizao e recuperao das descries dos servios, e ligaes ou invocao dos servios baseados nos servios de descrio. Essas maneiras podem ocorrer s ou interativamente com qualquer cardinalmente entre os papis. Em detalhes, essas operaes so: Publicao: para ser acessvel, um servio precisa publicar suas descries assim como o requisitante pode subseqentemente localiz-las. Localizao: Na operao de localizao, o requisitante do servio recupera uma descrio do servio diretamente ou perguntando pelo registro do servio requerido. A operao de localizao deve ser envolvida em duas fases de ciclos de vida para o requisitante do servio: no tempo de construo para recuperar a interface da descrio do programa desenvolvido, e na hora de execuo para recuperar a ligao do servio e descrio da localizao para invocao. Interao: eventualmente, um servio necessita ser invocado. A operao de interao do requisitante do servio invoca ou inicializa uma interao com o servio na hora de execuo usando os detalhes da descrio da ligao para localizao, contatar, e inovar o servio.

IV - Protocolos

A implementao de Web Services baseada em um conjunto de protocolos e linguagens padres 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 trs ltimos padres. De uma maneira geral, o protocolo SOAP define o formato que as mensagens transportadas na rede devem ter para encaminhar requisies a servios Web. Este protocolo tambm define o formato das mensagens de resposta s requisies. J o WSDL consiste em uma linguagem XML para a descrio de interfaces de servios, visando tornar essa descrio inteligvel para programas que iro interagir com esses servios.

Nas pginas seguintes ns 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 flexvel derivado do SGML. Originalmente projetado para encontrar chaves em documentos eletrnicos em larga escala, XML esta tambm se tornando um importante padro para a troca de uma vasta variedade de dados na web. Com o advento do XML tornou-se fcil para sistemas de diferentes ambientes trocarem informaes. A universalidade do XML tornou-se uma maneira muito atrativa para comunicao entre programas. Programadores podem usar diferentes sistemas operacionais, linguagens de programao etc. e ter seus softwares comunicando-se com outros de uma maneira ininterrupta. XML, XML namespaces e XML schemas so ferramentas teis para prover mecanismos para realizar acordos com estruturas extensas em um ambiente distribudo, especialmente quando usados em conjunto, XML namespaces e XML schemas sero abordados mais adiante. No mundo em geral, sistemas de computador e bancos de dados contm dados em formatos incompatveis, 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 so. HTML foi desenvolvido para mostrar dados e focar em como os dados aparecem. Com o XML os dados so 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 visualizao, e ter certeza que as mudanas em dados essenciais no iro requerer nenhuma mudana para o HTML.

24

Dados XML tambm podem ser armazenados dentro de pginas 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 informao financeira entre empresas na Internet, muitas aplicaes interessantes de B2B esto 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 usurios, pois independente de hardware; Pode ser usado para criar outras linguagens, XML a me do WAP e WML;

Exemplo de documento XML Documentos XML usam uma descrio prpria 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 ( declarao XML) define a verso do XML e a codificao dos caracteres usados no documento; A prxima linha descreve o elemento raiz do documento, como se fosse um ttulo; As prximas 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 so diferentes quando expressadas em maisculas ou minsculas diferentemente do HTML, portanto deve-se tomar o cuidado em digitar as tags da mesma forma na sua abertura e fechamento. Alm disso as tags devem merecer principal ateno no caso de sua insero, pois apresentam erros se forem inseridas de maneira errada, ex.: Abaixo nota-se a insero do <b><i> e o seu respectivo fechamento </i></b> a insero errada desse detalhe ocasiona erros no XML, diferentemente do HTML onde aceito essa inverso 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. Espaos em branco que so digitados em documentos XML no so levados em considerao no momento da visualizao. Novas linhas no XML so sempre armazenadas como LF, ou seja, no momento da impresso 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 impresso).

26

Elementos XML (XML elements) Elementos XML so extensveis e tem relacionamentos, possuem simples regras de nomes. Analisaremos o modelo abaixo: <note> <to>Tove</to> <from>Jani</from> <body>Don't forget me this weekend!</body> </note>

Podemos criar uma aplicao 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 a aplicao ainda ser capaz de localizar os elementos <to>, <from> e <body> e produzir o mesmo resultado anterior.

Elementos XML possuem relacionamentos Elementos so relacionados como pais (parents) e filhos (children). Imaginemos que essa seja a descrio 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 so elementos filhos (child element) do livro. Book o elemento pai (parent element) do elemento title, prod e chapter. Title, prod and chapter so irmos (siblings ou sister elements) porque eles tem o mesmo pai. Elementos podem ainda ter diferentes tipos de contedo. Um elemento pode ter elemento de contedo, contedo misturado, contedo simples, ou contedo vazio. Um elemento pode tambm ter atributos. No exemplo acima temos os seguintes: book, tem um elemento de contedo, porque contem outros elementos; Chapter, tem um contedo misturado, porque contem texto e outro elemento; Para, tem contedo simples, porque contem somente texto. Prod, tem contedo vazio, porque no carrega nenhuma informao.

Atributos XML Elementos XML podem ter atributos no incio da tag, sendo parecido com HTML. Atributos so usados para prover informaes adicionais sobre elementos.

28

De documentos HTML podemos lembrar isso: <IMG SRC="computer.gif"> . O atributo SRC prov informaes adicionais sobre o elemento IMG. No HTML e XML atributos provem informaes adicionais sobre elementos: <img src="computer.gif"> <a href="demo.asp">

Atributos geralmente provem informao que no so 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 pgina HTML, como mostrado abaixo: <xml id="note"> <note> <to>Tove</to> <from>Jani</from> <heading>Reminder</heading> <body>Don't forget me this weekend!</body> </note> </xml>

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

XML News O XMLNews uma especificao para troca de noticias e outras informaes. Permite produtores e consumidores de notcias produzir, receber e arquivar qualquer tipo de informao atravs de diferentes software, hardware e linguagens de programao.

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 aplicaes XML onde um nico documento pode conter elementos e atributos que so definidos para serem usados por mltiplos softwares, foram criados os Namespaces. Um XML Namespace uma coleo 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 computao em que a verso XML tem uma estrutura interna e no , matematicamente falando, um conjunto. XML Namespaces provem um mtodo de evitar conflitos de elementos em documentos XML. Desde que nomes de elementos em XML no so fixados, muito freqentemente um nome ir conflitar com outro ocorrendo dois tipos diferentes de documentos usando a mesma descrio de nomes para dois tipos diferentes de elementos.

30

Este documento XML carrega informao em uma tabela: <table> <tr> <td>Apples</td> <td>Bananas</td> </tr> </table>

Este documento XML carrega informao 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 contm 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 no se conflitam pois usam diferentes tabelas.

Usando Namespaces Este documento XML carrega informao 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 informao sobre uma pea: <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 invs 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 informaes 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 implementaes especficas. Os dois maiores objetivos do SOAP so 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 programao.

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 informaes de chamadas e repostas; Um elemento de falha opcional que prove informao 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 captulos 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

<?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"> ... 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 aplicao 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 contedo desse elemento para todos os elementos filhos (children elements). Sintaxe: soap:encodingStyle="URI"

Podemos visualizar um exemplo do encodingStyle nesse modelo: <?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"> ... Message information goes here ... </soap:Envelope>

34

Header SOAP

O elemento Header (cabealho) contem informao especfica da aplicao, 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. <?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> <m:Trans xmlns:m="http://www.w3schools.com/transaction/" soap:mustUnderstand="1">234</m:Trans> </soap:Header> ... ... </soap:Envelope>

O exemplo acima contem trs atributos contendo um cabealho com um elemento Trans um atributo mustUnderstand com valor de 1 e 234. SOAP define trs atributos em Namespace padro ("http://www.w3.org/2001/12/soapenvelope"). Esses atributos definidos no cabealho 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 invs disso, devem planejar um ou mais endpoints no caminho da mensagem. O atributo actor deve ser usado para enderear o cabealho para um endpoint particular.

35

Sintaxe actor: soap:actor="URI" Exemplo: <?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> <m:Trans xmlns:m="http://www.w3schools.com/transaction/" 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 cabealho de entrada obrigatrio ou opcional para o processo. Se adicionarmos mustUnderstand=1 para um elemento child do cabealho este indicara que o processo recebedor do cabealho deve reconhecer o elemento. Se o recebedor no identificar o elemento este deve falhar quando processar o cabealho. Sintaxe: soap:mustUnderstand="0|1" Exemplo: <?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> <m:Trans xmlns:m="http://www.w3schools.com/transaction/" 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 concluso 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 padro ("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 servios de rede como um conjunto de operaes como ponto final nas mensagens contendo cada documento orientado ou informao orientada. As operaes e mensagens so descritas de forma abstrata e ento o salto para um protocolo de rede concreto e formato de mensagens para definir um ponto final. WSDL extensvel para permitir descrio do ponto final e suas mensagens no levem em considerao de quais formatos de mensagens ou protocolos de rede so usados para comunicao. Como protocolos de comunicao e formatos de mensagens so padronizadas na comunidade web, isso se torna crescente a possibilidade e importante ser capaz de descrever as comunicaes em alguma forma de estrutura. Esses endereos WSDL necessitam pela definio de uma gramtica XML para descrever servios de rede como colees de pontos finais de comunicaes capazes de trocar mensagens. As definies de servios WSDL provem documentao para sistemas distribudos e servem como um recipiente para detalhes de automao envolvidos em aplicaes de comunicao. Um servio WSDL define documentos como colees de pontos finais de rede, ou portas. No WSDL, a definio abstrata de pontos finais e mensagens so separadas de suas organizaes de redes concretas ou formatos de dados de comunicao. Isto permite a reutilizao de definies abstratas: mensagens, que so descries abstratas dos dados sendo trocados, e tipos de portas que so colees abstratas de operaes. O protocolo concreto e especificaes de dados concretos para uma tipo de porta em particular constitudas como comunicaes reutilizveis. Uma porta definida associando um endereo de rede como

37

ligao reutilizvel, e uma coleo de portas definindo um servio. Daqui, um documento WSDL usa os seguintes elementos em sua definio dos servios de rede:

Estrutura WSDL Types (tipos) Um recipiente para definio de tipos de dados usando alguns tipos de sistemas. WSDL usa sintaxe XML para definir tipos de dados. Message (mensagens) Um resumo de definies de tipos de dados sendo trafegados, podem conter uma ou mais partes, esses partes podem ser comparadas parmetros de uma funo. portType (Tipo de porta) Um resumo da configurao das operaes suportadas por um ou mais endpoints. Binding (Ligao): 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 operaes desempenhadas e mensagens que esto envolvidas. Operation Types (Tipos de operao) One-Way A operao pode receber uma mensagem mas no ir retornar uma resposta. Request-responde A operao pode receber uma requisio e retornar uma resposta. Solicit-response A operao pode enviar uma requisio e esperar por uma resposta Notification A operao pode enviar uma mensagem mas no ir

Bindings SOAP O elemento Binding tem dois atributos, name e type, o atributo name define o nome da ligao, e o type indica o ponto para a ligao 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 constri Web services, esses servios necessitam ser acessados em algum lugar na Web por uma aplicao-cliente. Uma forma de se acessar um Web service fazer com que a aplicao-cliente conhea a URI do servio, desta maneira caracterizando o modo esttico de se localizar e acessar um servio. Entretanto, quando a aplicao-cliente no detm, a priori, a localizao de um Web service, esse, pode ser descoberto antes de ser acessado caracterizando o modo dinmico de se descobrir a localizao de um servio. UDDI uma especificao tcnica para descrever (describing), descobrir (discovering) e integrar Web services. Assim, portanto, uma parte crtica da pilha de

39

protocolos Web services, habilitando usurios dos servios a publicarem e descobrirem estes servios. Discovery o processo de localizar Web services atravs de registries. Registries de Web services so repositrios contendo documentos que descrevem dados de negcios. Registries, tambm, proporcionam caractersticas tais como, capacidade de busca e acesso programtico para aplicaes remotas. Usando um registry, uma organizao que deseja utilizar, por exemplo, um servio para processar pagamentos de tickets de alimentao, pode localizar todos os servios disponveis publicamente, que proporcionam a necessria funcionalidade. A organizao pode comparar servios e ento decidir qual servio melhor se ajusta s necessidades da organizao. 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 servio. Dados obtidos por Discovery direto so mais precisos e, portanto, confiveis, visto que a organizao que prov a informao tambm opera o servio na Web. Discovery indireto Com Discovery indireto, uma organizao obtm dados atravs de uma terceiro registry, cujos dados podem no ser precisos, porque provedores de servio poderiam no atualizar as informaes nesse registry to freqentemente. Quando realizando Discovery indireto, organizaes devem colocar a seguinte questo: quo freqente, terceiros registries interagem com provedores de servio para garantir que os dados so ainda precisos? Embora discovery indireto tenha seus drawbacks, ele ainda permite avaliar servios de vrios provedores antes do compromisso para usar um servio particular. Em seu ncleo, UDDI consiste de duas partes: API UDDI e UDDI Business Registry.

API UDDI uma especificao tcnica para construir um diretrio distribudo de negcios (business) e Web services. A informao UDDI armazenada dentro de um formato

40

especfico XML, definido por WSDL e XML Schema. A especificao inclui detalhes de uma API prpria para buscar dados existentes ou publicar novos dados.

UDDI Business Registry Tambm conhecido como UDDI cloud services uma implementao operacional completa da especificao UDDI. Tal parte habilita qualquer um a buscar dados UDDI existentes, e tambm, a qualquer empresa registrar-se a si prpria e seus respectivos servios. A informao capturada no contexto UDDI so classificadas em trs categorias principais:

Pginas Brancas (White Pages) Essas incluem informaes sobre uma empresa especfica, como por exemplo, nome de um negcio, descrio do negcio, informao de contato, endereo, nmeros de telefone, fax, ou mesmo incluir identificadores de negcios (business identifiers), no formato de classificaes Dun & Bradstreets D-U-N-S (Data Universal Numbering System), que so nmeros de nove dgitos atribudos a negcios. A especificao UDDI verso 2.0 oferece suporte para identificadores especficos de indstrias, tal como o sistema do Standard Industrial Classification (SIC), o qual atribui identificadores numricos nicos a indstrias. Por exemplo, 7371 representa Servios de Programao de Computadores e 2621 representa Paper Mills.

Pginas Amarelas (Yellow Pages) Essas incluem dados de classificao geral para qualquer empresa ou servio oferecido. Por exemplo, esses dados podem incluir a indstria, o produto, ou cdigos geogrficos baseados sobre taxionomias padronizadas.

41

Pginas Verdes (Green Pages) Esta categoria contm informao tcnica sobre um servio na Web (Web service). Geralmente, essa informao inclui um apontador (ponteiro) para uma especificao externa e um endereo para invocar o servio. UDDI no restrito a descobrir servios baseados em SOAP. Ao contrrio, pode ser usado tambm, para descrever qualquer servio, desde uma nica pgina Web ou endereos de e-mail, at servios CORBA, Java RMI, ou mesmo, servios EJB.

Arquitetura UDDI A arquitetura tcnica de UDDI consiste de trs partes: Um Modelo de Informao UDDI, o qual baseia-se num XML Schema para descrever negcios e Web Services, uma API UDDI baseada em SOAP para publicao e busca de informao UDDI e no UDDI Business Registry (UBR) os quais so os sites-operadores que provem implementaes da especificao UDDI e sincronizam todos os dados sobre uma scheduled basis. Exemplos de UBRs providos por grandes corporaes, so Microsoft, IBM, HP, SAP e NTT Communications do Japo

42

Sites-Operadores Um site-operador uma organizao que hospeda uma implementao do UDDI Business Registry (UBR). Uma empresa usuria de UDDI necessita registrar-se somente em um site-operador, conhecido como custodian. O princpio bsico do UDDI para um UBR aquele de que uma empresa registra uma vez e publica em qualquer lugar. Princpio que afirma, que a informao contida em um UBR custodian replicada sobre os outros UBRs. Replicao o processo de atualizar registros, de modo que todas as instncias daqueles registros originais sejam idnticas. Assim, uma empresa registra os seus dados em um siteoperador (custodian) e esses aparecem nos outros sites-operadores. At a verso UDDI 2.0, uma empresa podia atualizar sua informao somente atravs de seu site-operador custodian. Isto porque, a especificao da API verso 2.0 de UDDI no provia um protocolo para reconciliar diferentes verses de UDDI. Tal limitao requer interao com somente um siteoperador, proibindo, assim, usurios de entrarem em mltiplas verses de modelos de informao em diferentes sites-operadores. Os UDDI Business Registries (UBRs) proporcionam um diretrio de sistesoperadores UDDI, fisicamente distribudo, mas logicamente centralizado. Isto significa que dados submetidos a um site-operador sero automaticamente replicados atravs de todos os outros sites-operadores. Tal replicao no ocorre instantaneamente, mas os sites-operadores se sincronizam para atualizao de registros, em intervalos de tempo diariamente. tambm possvel estabelecer registros UDDI privados. Por exemplo, uma grande empresa pode estabelecer seu prprio sistema UDDI privado, para registrar todos os seus servios Web internos empresa. Quando esses servios no so automaticamente sincronizados com os sites-operadores UDDI, eles no so considerados partes do conjunto de UDDI Business Registries (os cloud services). Registrars Empresas usurias de UDDI podem tambm publicar informao em um UBR, atravs de uma organizao chamada registrar uma outra empresa que auxilia na criao de informao de negcios e descries de Web services, a serem armazenados nos UBRs. Uma empresa registrar no um site-operador, porque essas empresas no hospedam implementaes de UDDI Business Registry.

V - Segurana

Quando planejamos aplicar os Web Services no apenas nos conceitos e em aplicaes demo, mas efetivamente no mundo real, a preocupao com segurana desperta especial ateno. Pela grande diversidade de sistemas que compem atualmente os vrios ambientes de TI, necessrio que haja uma abordagem modular questo de segurana em Web Services. Na medida em que cresce o uso de Web Services entre empresas que adotam diferentes modelos de segurana em sua colaborao, as especificaes de segurana e confiabilidade propostas devem oferecer um modelo flexvel, que permita a essas empresas se interconectarem de forma confivel. Como sabemos, Web services utilizam o protocolo SOAP em sua comunicao, o qual baseado em XML, ou seja, um arquivo texto perfeitamente legvel. Para tornar um WEB service seguro voc deve encriptar a comunicao e existem duas maneiras de se fazer isso: garantir a segurana ao nvel de transporte e ao nvel de XML.

Segurana ao nvel de Transporte SSL Segurana ao nvel de transporte significa proteger o protocolo de rede que o Web service utiliza para se comunicar. O Secure Sockets Layer (SSL) um protocolo padro para encriptar comunicaes sobre TCP/IP. Neste modelo, um cliente abre um socket seguro para um Web service e ento o utiliza para trocar mensagens SOAP via HTTPS.

44

A implementao de SSL garante segurana encriptando todo o trfego de rede sobre o socket. Utilizando-se SSL pode-se tambm autenticar um Web service para um cliente utilizando-se um Certificado Digital atravs da Infra-estrutura de Chaves Pblicas (PKI).

PKI Garantir segurana na Internet requer mecanismos seguros para a troca de informaes, mas que alm disso sejam modulares e permitam garantir a segurana em sistemas distribudos. A Infra-estrutura de Chaves Pblicas (PKI) garante a segurana de comrcio eletrnico e de comunicaes na Internet atravs dos seguintes elementos: Autenticao - verificar a identidade dos usurios e das mquinas torna-se crucial quando uma organizao abre suas portas para a Internet. Mecanismos de Autenticao robustos, como o PKI, verificam a identidade sem permitir a transmisso ou o armazenamento de senhas reutilizveis. Eles certificam-se de que as pessoas ou mquinas sejam as entidades que dizem ser. Esta tarefa geralmente feita por um terceiro envolvido no processo, o qual pode ser uma empresa de autenticao confivel ou um servio de certificao que utiliza criptografia convencional. O uso adequado de PKI torna virtualmente impossvel que uma pessoa no autorizada acesse o sistema. Encriptao - Encriptao e algoritmos de integridade so utilizados para proteger comunicaes e garantir a privacidade durante o envio de dados de um computador a outro. Estes processos garantem que os dados mantenham-se confidenciais, que no sejam modificados e que a perda de pacotes possam ser identificadas. No repdio - No repdio significa que os remetentes de e-mails ou transaes assinadas digitalmente no podem alegar que no a transmitiram. Assinaturas digitais utilizando PKI podem garantir com segurana que a pessoa que assina a transmisso eletrnica realmente aquela pessoa, uma vez que ningum mais pode criar aquela assinatura digital. Uma assinatura digital PKI prova que um determinado usurio realizou certas operaes no sistema. Para a criptografia de chaves pblicas, entidades que desejem se comunicar de uma maneira segura devem utilizar algumas credenciais seguras. As credenciais seguras consistem em Chaves Pblicas e Privadas. Esta forma de criptografia usa uma chave privada secreta e

45

uma chave pblica relacionada matematicamente chave privada. Somente a chave pblica pode ser utilizada para encriptar a informao, e somente a chave privada correspondente pode ser usada para decript-la. Somente o proprietrio do par de chaves conhece a chave privada, enquanto a chave pblica pode ser amplamente distribuda e mantm-se associada ao proprietrio. A mensagem encriptada com a chave pblica pode ser somente decriptada pelo proprietrio, o qual conhece a chave privada associada. Estas chaves tambm so utilizadas em assinaturas digitais para prevenir que um indivduo se faa passar por outro ou prevenir repdio de mensagens vlidas. Certificados Digitais - Certificados so identidades digitais atribudas por uma terceira entidade que identifica os usurios e as mquinas. Os certificados so atribudos quando a entidade certificadora recebe e valida as informaes as informaes solicitadas. Os certificados podem ento ser seguramente armazenados em carteiras ou diretrios e utilizados para fornecer a validao de identidade a qualquer entidade na Internet. Entidade Certificadora - a Entidade Certificadora um terceiro agente envolvido que atua como um provedor independente e confivel de certificados digitais. O uso de um par de chaves criptografadas para criar um canal de comunicao seguro, garante a privacidade da mensagem e proporciona a possibilidade de validao do remetente. A ampla distribuio da chave pblica no afeta a sua segurana pois a chave privada nunca compartilhada. A chave pblica de um indivduo publicada por um Entidade Certificadora em um certificado atribudo ao usurio. As entidades que desejarem trocar informaes seguras podem codificar a informao com a chave pblica da entidade destinatria. Uma entidade que receba uma comunicao codificada por este mtodo pode usar sua prpria chave privada para decodificar a mensagem. Se a mensagem original no for decodificada usando a chave adequada o resultado da decodificao ser ilegvel.

IPSec Descrevendo ainda a segurana ao nvel de transporte, o projeto IPSec representa um esforo desenvolvido pelo Working Group IPSec da IETF para desenvolver uma arquitetura de segurana para o protocolo IP, integrando mecanismos de autenticao, gesto e distribuio de chaves que podem ser usados com qualquer das verses do protocolo IP.

46

Atravs dos seus componentes, a IPSec usa este conceito para permitir a implementao de redes virtuais privadas e seguras atravs de redes pblicas tais como a Internet. O IPSec utiliza como mecanismos de autenticao dois cabealhos de extenso especficos do protocolo IPv6: o cabealho de Autenticao (Authentication Header) e o cabealho de encapsulamento de dados de segurana (Encapsulating Security Payload Header). Alm destes dois cabealhos, o IPSec define tambm o conceito de associao de segurana, conjunto de diretivas que permite negociar algoritmos de encriptao a serem utilizados. O IPSec integra gesto manual de chaves. A gesto de responsabilidade de protocolos criados para este fim. Os componentes da IPSec so, o Cabealho de Autenticao (AH), o Cabealho de Encapsulamento de Dados de Segurana (ESP) e os Mecanismos de Gesto de Chaves. Cabealho de Autenticao - O cabealho de autenticao representa um cabealho de extenso do protocolo IPv6 e foi criado para validar a identidade de entidades que esto 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 autenticao aos datagramas IP. Na medida em que alguns dos campos do datagrama IP so alterados durante a transmisso e dado que o cabealho de autenticao adicionado na fonte do datagrama, este cabealho por si s no fornece proteo contra ataques de anlise de trfego ou confidencialidade, sendo para tal usado normalmente em conjunto com o cabealho de encapsulamento de dados. Cabealho de Encapsulamento de Dados de Segurana - O cabealho de encapsulamento de dados de segurana (ESP) um cabealho de extenso pertencente ao protocolo IPv6 que fornece integridade e confidencialidade aos datagramas IP atravs da cifra dos dados contidos no datagrama. A utilizao do ESP pode ser efetuada de dois modos: Modo de Transporte (transport-mode) - Providencia proteo principalmente no respeitante aos protocolos da camada superior. Este modo encripta informao do protocolo da camada de transporte, adicionando-lhe de seguida um novo cabealho IP no-encriptado, pelo que se torna vantajoso em redes relativamente pequenas, nas quais o(s) servidor(es) e n implementam o IPSec.

47

Modo de Tnel (tunnel-mode) - Providencia proteo ao pacote IP. Para tal, aps a adio dos campos ESP ao pacote IP, todo o pacote tratado como o mdulo de dados de um novo pacote IP. Assim, pode ser usado para enviar dados encriptados atravs de um tnel, o que permite enviar dados independentemente da infra-estrutura utilizada. Um exemplo o envio de pacotes IP atravs de canais virtuais criados numa rede IP pblica, como a Internet. Atravs deste modo, pode ser fornecida segurana a um grupo de ns que no implementem o IPSec. Mecanismos de Gesto de Chaves - Alm dos mecanismos de autenticao e validao da informao a IPSec necessita de um mecanismo eficiente de gesto de chaves. A gesto de chaves diz respeito criao, eliminao e alterao das chaves. Embora o IPSec no integre um mecanismo de gesto de chaves, a IETF definiu como norma de gesto o protocolo hbrido ISAKMP/Oakley tambm 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 gesto de associaes de segurana; Oakley - protocolo que define material de chaves para cifra, hashing e

autenticao e compatvel com a gesto de associaes de segurana ISAKMP; Internet Domain Of Interpretation - define parmetros ISAKMP para as

associaes de segurana IPSec no domnio Internet; Resoluo ISAKMP/Oakley define o perfil do protocolo hbrido

ISAKMP/Oakley, escolhido como norma de gesto de chaves criptogrficas pela Internet Engineering Task Force; IKE - Internet Key Exchange.

Segurana ao nvel de XML Por sua vez, segurana ao nvel de XML envolve a encriptao e decriptao de documentos XML. O World Wide Web Consortium (W3C), o qual mantm o padro XML, tem criado grupos de trabalhos para definir padres para segurana em XML, incluindo assinaturas digitais, encriptao e gerenciamento de chaves para XML.

48

XKMS (XML Key Management Services) Esta especificao estabelece um formato de documento em XML que permite que a autenticao de chaves e gerenciamento de certificados sejam feitos em aplicaes Web. A XKMS permite um nvel mais profundo de interoperabilidade entre sistemas de PKI, ao mesmo tempo em que permite uma integrao mais fcil entre as aplicaes 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. se uniram e publicaram um conjunto de novas especificaes de segurana denominadas WSSecurity, com o objetivo de que as empresas pudessem criar e construir aplicaes de Web Services com ampla interoperabilidade. As especificaes do WS-Security, propostas pela IBM e Microsoft, so fundamentais para a concretizao de um planejamento amplo de recursos que possam atender crescente necessidade de oferecer suporte mais seguro para construo de Web services. O documento "A Segurana no mundo dos Web services", de autoria da Microsoft e da IBM, explica as novas especificaes de segurana para Web Services que essas empresas pretendem desenvolver em conjunto com alguns de seus principais clientes, parceiros de mercado e entidades responsveis pela padronizao. O WS-Security suporta, integra e unifica vrios modelos, mecanismos e tecnologias de segurana em uso no mercado, permitindo que vrios sistemas possam interoperar em plataformas e linguagens neutras. As novas especificaes de segurana definem um conjunto de padres para extenses SOAP (Simple Object Access Protocol) ou para cabealhos de mensagens, utilizados para oferecer maior integridade e confidencialidade s aplicaes de Web Services. O SOAP um protocolo baseado na linguagem XML, com acesso a diferentes plataformas ou linguagens. O WS-Security oferece os mecanismos-padro de segurana necessrios para realizar o intercmbio seguro de mensagens certificadas em um ambiente de Web Services. Alm da divulgao das especificaes WS-Security, a IBM e a Microsoft anunciaram tambm a publicao do projeto "A Segurana no mundo dos Web Services" ("Security in a

49

Web Services World"). Esse documento define alguns recursos adicionais de segurana de Web Services que se enquadram no modelo estabelecido pelas especificaes WS-Security, entre eles: WS-Policy, WS-Trust e WS-Privacy - O WS-Policy define como os recursos e restries das normas de segurana podero ser expressos; o WS-Trust ir descrever um modelo para que se obtenha um relacionamento de confiana, tanto direto, quanto por meio de agentes (incluindo terceiros e intermedirios); o WS-Privacy determinar de que forma os Web Services sero adotados e implementados. WS-Secure Conversation, WS-Federation e WS-Authorization - O WS-Secure Conversation explica como autenticar e gerenciar a troca de mensagens, incluindo especificaes para o contexto de segurana desse intercmbio e a derivao de chaves de sesso; o WS-Federation gerencia os vrios tipos de relacionamento em ambientes heterogneos associados, incluindo o suporte identidade dessas partes associadas; a WSAuthorization define como os Web services administraro os dados e as normas de autorizao.

VI - Aplicao de WS em B2B

Nos ltimos anos diversos padres foram propostos para a implementao do conceito de sistemas distribudos. Um modelo muito popular tem sido o de separao de uma aplicao em camadas, apresentao, negcio e dados. Este modelo, usado exausto na Internet, tem por base uma infinidade de protocolos, dos quais DCOM e CORBA so os mais conhecidos. Embora estes protocolos sejam muito diferentes entre si, seus problemas so basicamente os mesmos: complexidade de implementao e, principalmente, implantao. Sistemas escritos em diferentes linguagens, e no raro em plataformas distintas, sofrem ainda de um mal bem mais grave, a incompatibilidade entre os tipos de dados, alm da necessidade de forte envolvimento das equipes tcnicas de ambos os lados no processo de integrao. Estas tm sido as principais causas da baixa integrao entre os sistemas de clientes e fornecedores mesmo com toda a facilidade de infra-estrutura de comunicao existente hoje em dia. Com a facilidade proporcionada por esta tecnologia para a integrao entre sistemas, adotar o modelo de computao distribuda atravs de Web Services pode ser um enorme diferencial competitivo em um futuro prximo. Para as empresas, os Web Services significam agilidade nos processos e eficincia na comunicao entre cadeias de produo ou logstica. Toda e qualquer comunicao passa a ser dinmica e, principalmente, segura, pois no prev interveno humana. possvel formatar regras de negcios e criar fluxos de informaes especficas, entre outros recursos que otimizam as relaes entre parceiros corporativos. Para os usurios 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 preo e em qual prazo de entrega. Mediante estes dados, exibe para o consumidor a melhor oferta. Do ponto de vista da loja, alm de melhorar o servio, ocorre uma reduo drstica nos estoques e, consequentemente, no capital de giro demandado. Abaixo, temos uma figura que ilustra o ciclo da aplicao mostrado a interao entre os diversos agentes envolvidos na operao:

1. cliente solicita um servio ao Servidor Web atravs da Internet ou Intranet. 2. Servidor Web entra em ao, acessando a sua base de dados local para obter parte das informaes a serem devolvidas ao Browser. 3. A aplicao Web faz acesso a um servio Web Service, que executado em um servidor de plataforma desconhecida. Neste momento o contexto da aplicao 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 informao solicitada. 5. Web Service devolve a informao ao aplicativo servidor Web solicitante 6. Servidor Web mescla as informaes obtidas localmente (2), com as informaes obtidas do Web Service (5), retornado-os ao Browser solicitante.

52

Vantagens e Desvantagens do WS A utilizao da Internet como infra-estrutura de comunicao para sistemas distribudos tem despertado um interesse cada vez maior de pesquisadores e empresas. Porm a insegurana da Internet leva a implementaes de polticas de segurana que comprometem a funcionalidade dos sistemas distribudos. A adoo de middlewares baseados em protocolos de comunicao especficos tem tido grande sucesso em redes locais e corporativas onde restries de segurana so planejadas considerando a existncia de middlewares nas redes. Entretanto, na Internet necessitamos de alteraes especficas em Firewalls, o que nem sempre possvel. Por estes problemas, arquiteturas como CORBA no tem conseguido uma utilizao massiva na Internet. Para contornar estas restries, devemos procurar uma alternativa compatvel com os servios existentes atualmente e aproveitar todo o suporte existente para estes na Internet. No caso especfico de CORBA, protocolos para tunelamento de IIOP em HTTP foram desenvolvidos por empresas. Entretanto, estes protocolos no seguem nenhum padro, o que pode causar problemas de interoperabilidade entre diversas implementaes de ORBs. Um Web Service tem por objetivo o fornecimento de um servio ou funcionalidade, que pode ser consumido por uma aplicao ou ainda por outro Web Service. Esse servio pode ter um retorno simples como a validao de um CPF ou uma informao mais detalhada como o nome da Cidade, do Estado e da Rua a qual se refere um determinado CEP. Alm disso, a arquitetura dos Web Services independente de plataforma, o que garante uma maior portabilidade. Para que isso seja vivel, necessrio prover mecanismos padro de definio, transporte, localizao e publicao desses servios 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 integrao e oferta de servios pela Web, eles se utilizam de protocolos padro amplamente difundidos (SOAP, HTTP, WSDL), um formato padro de troca de informaes (XML) e um diretrio de registro e localizao (UDDI). Esses fatores ento fornecem os pr-requisitos para a sua larga aceitao, em contraste com solues como

53

CORBA ou COM+ que esto ligadas a um protocolo adicional especfico que precisa ser conhecido pelas camadas que se comunicam. Um outro fator estratgico de aceitao a convergncia de grandes fornecedores de software tais como IBM, Microsoft, Hewlett-Packard e SUN em relao a padres de definio dessa arquitetura, embora cada uma dessas organizaes tenha uma implementao de Web Services ligeiramente diferente das outras. importante perceber que os objetos distribudos que seguem o padro CORBA ou J2EE podem continuar sendo uma escolha mais acertada se considerado seu uso dentro do ambiente corporativo de uma empresa. Objetos distribudos so projetados para troca de objetos em formato binrio, de tipos especficos em um processo sncrono de troca de mensagens. Esse fato, aliado dependncia de plataforma, possibilita um alto desempenho e um baixo acoplamento dos objetos distribudos, tendo sido estes usados com sucesso em muitas solues de sistemas. J os Web Services so mais adequados para ambientes de distribuio de escopo mais amplo. Por exemplo, podem ser usados para troca de documentos entre parceiros de negcio (muitas vezes de forma assncrona), uma vez que se utilizam de XML e HTTP, permitindo ultrapassar a barreira dos Firewalls, sendo independente de plataforma e facilitando assim a comunicao e a troca de informaes. Os Web Services, por outro lado, provavelmente no apresentaro um alto desempenho como componentes de sistemas voltados para dentro da empresa, devido ao tamanho e sobrecarga necessria para o tratamento dos documentos XML, enquanto que os objetos distribudos so mais adequados para a construo de sistemas de alto desempenho com uma arquitetura bem definida. Outra desvantagem do uso dos Web Services atualmente o fato de a tecnologia ser ainda muito recente, estar pouco difundida e ainda estar sendo padronizada em muitos aspectos pelo W3C. Assim, ainda h problemas quanto aos aspectos de localizao dos servios, tratamento de transao e segurana. Esses aspectos, no entanto, esto sendo estudados e existe um grande interesse por parte dos grandes fornecedores de software de resolv-los, sendo ao que tudo indica uma questo de tempo e no de rumo. A questo da segurana, por exemplo j se encontra melhorada com a verso 3.0 do UDDI. O futuro, cada vez mais prximo, como deixam perceber os investimentos dos fornecedores, est alinhado com os Web Services.

VII - Como o Mercado apoia o padro

A tecnologia de Web Services tem sido focada em promover a colaborao B2B via processos de negcios integrados. Mas o real benefcio dos Web Services pode ser liberado na tecnologia de BI (Business Intelligence) e no no processamento de transao. Companhias estratgicas que desenvolvem aplicativos de negcios assim como Oracle, SAP, PeopleSoft, Siebel Systems entre outras, esto construindo frameworks de Web Services nos seus produtos podendo com isto estimular a demanda de BI em rede, atravs da mudana de cultura do relacionamento corporativo no comrcio colaborativo. Observe como as principais empresas e organizaes esto se posicionando no mercado em relao ao desenvolvimento e fortalecimento do padro.

Microsoft A Microsoft est promovendo .NET como iniciativa de Web Service, que requer o uso de software baseado em Windows. Alm disso, a Microsoft tem planos de transformar programadores fluentes no Windows em projetistas Web Services, com a liberao de um conjunto de ferramentas de desenvolvimento, Framework .NET.

Sun Microsystems A Sun Microsystems, de outro lado, est liderando uma estratgia 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 padres (SOAP, WSDL, UDDI) e tambm tem compatibilidade com a plataforma Microsoft .NET.

META Group A previso do META Group para Web Services que os padres inicialmente desenvolvidos para propiciar a integrao e interoperabilidade (XML, WDSL, UDDI, etc.) chegaro ao binio 2005/2006 com o status de arquitetura orientada a novos servios, desbancando o "mito" orientados a componentes como J2EE, CORBA e COM+. Segundo o META Group at 2004, novas aplicaes corporativas surgiro de componentes baseados ou integrados s tecnologias Java 2 Enterprise Edition (J2EE) e a Microsoft .Net, e que os fornecedores destas solues devem se diferenciar com a oferta de valor agregado, como Servios Web e de desenvolvimento de produtos e/ou ferramentas especficas.

OASIS O OASIS (Organization for the Advancement for Structured Information Standards) uma organizao criada para estabelecer padres para Web Services. formada por um Comit Tcnico criado para desenvolver um Modelo de Componentes para Servios em Web (WSCM). Este comit tem membros como Epicentric Inc., Hewlett-Packard, IBM, Macromedia Inc., entre outros. Dentro do Comit Tcnico WSCM existe o grupo de trabalho "Working Group Web Services User Interface" (WSUI) que submeteu as primeiras especificaes ao OASIS para consideraes do WSCM. O comit tem duas grandes metas: habilitar negcios para distribuir aplicaes na Web atravs de mltiplos canais de revenda e habilitar novos servios ou aplicaes a serem criados ou liberar as aplicaes existentes atravs da Web. Isto deve permitir que as companhias possam transferir Web Services atravs de Portais e Plataformas, indiferente de produtos proprietrios.

56

TechMetrix Research Veja no grfico abaixo o que a pesquisa da TechMetrix revelou sobre a iniciativa das empresas em utilizar a tecnologia de Web Services construdos 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 devero dominar at 2004, enquanto Web Services melhoram o seu desempenho. Por volta de 2006, companhias devem adotar Web Services bsicos, e ampliar o uso da tecnologia para transaes mais complexas. Analistas da Forrester aconselham aos executivos para iniciar o trabalho em Web Services bsicos com parceiros e internamente, monitorando a evoluo de padres de Web Services para identificar capacidades mais promissoras para mais tarde adotar.

VIII Concluso

Como foi visto neste trabalho, Web Services um novo modelo de aplicao Web que combina aspectos de desenvolvimentos baseados em componentes reutilizveis. Este modelo est tendo uma aceitao muito grande no mercado alm do apoio de grandes indstrias de software, como Microsoft, IBM e Sun. Os componentes Web services podem ser utilizados sem nenhuma preocupao de como foram implementadas e podem ser facilmente compostos com diversos componentes para fornecer servios complexos. Apesar de ter ainda poucos anos de existncia, a tecnologia de Web Services est alcanando maturidade notvel. Grandes empresas esto apoiando a definio dos padres adotados e a questo de segurana que envolve as transaes tambm est recebendo a devida ateno. Contudo, a adoo desta nova tecnologia, como sempre ocorre nestes casos, est sendo feita com bastante cautela, existindo poucos cases no mercado disponveis para estudo dos acertos e falhas na implementao. A aposta da indstria que at 2005 um enorme volume de servios seja gerado por conta das integraes entre as empresas.

Referncias

http://www.w3.org http://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.