A Estrutura de um Web Service

  • 1,769 views
Uploaded on

Atualmente, o Serviço Web é a solução mais utilizada para integração entre sistemas, pois apresenta vantagens como independência de plataforma, baixo acoplamento e interoperabilidade entre aplicações. …

Atualmente, o Serviço Web é a solução mais utilizada para integração entre sistemas, pois apresenta vantagens como independência de plataforma, baixo acoplamento e interoperabilidade entre aplicações. Além disso, é uma tecnologia barata, pois se baseia em padrões abertos da Internet. Com base nisto este trabalho apresenta a estrutura básica, tecnologias e a forma de funcionamento de um Serviço Web. Também são apresentadas características positivas e negativas desta tecnologia.

More in: Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
1,769
On Slideshare
0
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
58
Comments
0
Likes
1

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. A Estrutura de um Web Service Paulo Vitor Antonini Orlandin paulovitor_e@hotmail.comResumoAtualmente, o Serviço Web é a solução mais utilizada para integração entresistemas, pois apresenta vantagens como independência de plataforma, baixoacoplamento e interoperabilidade entre aplicações. Além disso, é uma tecnologiabarata, pois se baseia em padrões abertos da Internet. Com base nisto este trabalhoapresenta a estrutura básica, tecnologias e a forma de funcionamento de um ServiçoWeb. Também são apresentadas características positivas e negativas destatecnologia.Palavras chave: Serviços Web. WSDL. UDDI. XML. Web Service. SOAP.1. Introdução Com a grande necessidade de integração entre sistemas computacionais quena maioria das vezes são heterogêneos, e que normalmente não se comunicam porfalta de um padrão, surgiu o conceito de Serviços Web. Para que seja possível a integração de sistemas e aplicações diferentes autilização do Simple Object Access Protocol (SOAP)1 se torna indispensável. Graçasa esta tecnologia a troca de informações entre novas e antigas aplicações se tornapossível, bem como integração entre aplicações desenvolvidas em plataformasdiferentes. Cada aplicação pode ter sua própria linguagem, que é traduzida para oformato XML2, formato em que as mensagens são enviadas e recebidas (BOOTH etal., 2004). Um serviço que esteja disponível na Internet se comunicando de formapadronizada utilizando XML, provendo interoperabilidade entre sistemas e apoiando-se sobre os protocolos da Internet é um Serviço Web (BOOTH et al., 2004).1 Service Oriented Architecture (SOA)2 Disponível em <http://www.w3.org/XML/>. Acesso em: 25/02/2009. 1
  • 2. As mensagens recebidas e enviadas são estruturadas como documentosXML, que são encapsulados pelo protocolo SOAP3 e transportados via HTTP. Alinguagem WSDL4 é utilizada para descrever os serviços, que são: publicados,procurados, descobertos e divulgados utilizando o protocolo UDDI5 (BOOTH et al.,2004). Atualmente o método mais utilizado por quem busca integrar suas aplicaçõesé uma arquitetura SOA baseada em Serviços Web. SOA é uma arquitetura desoftware cujo princípio fundamental é que as funcionalidades implementadas pelasaplicações devem ser disponibilizadas na forma de serviços. É um paradigma dedesenvolvimento de software cujos demais objetivos são: buscar por flexibilidade,reutilização, fraco acoplamento e dinamismo na localização de serviços. O modelo atual de arquitetura SOA é composto por três entidades:Consumidor, Provedor, e Registrador de serviços. • Provedor: Responsável pela descrição de um serviço. Esta descrição é um documento WSDL que contém várias informações do serviço, como por exemplo, informações sobre parâmetros, end point, dados do criador. Também é encarregado de publicar os serviços em uma entidade registradora. • Consumidor: Responsável por obter o documento WSDL do serviço desejado. Posteriormente, utilizar as informações fornecidas por este documento fazer a ligação com o provedor, invocando um Serviço Web. • Registrador: Entidade responsável por armazenar as informações disponibilizadas pelos provedores em um diretório. É nesta entidade que o consumidor procura por um serviço. Atualmente a maioria das empresas vem adotando os Serviços Web embusca de interoperabilidade para suas aplicações. Além disso, os Serviços Webpodem trazer eficiência na comunicação interna de uma empresa e assim agilizandoos processos da mesma.3 Disponível em < http://www.w3.org/TR/soap>. Acesso em: 25/02/2009.4 Disponível em < http://www.w3.org/TR/wsdl>. Acesso em: 25/02/2009.5 Disponível em < http://uddi.xml.org/>. Acesso em: 27/02/2009. 2
  • 3. 2. Serviços Web Antes da criação da World Wide Web (WWW6) por Tim Berners-Lee no fim dadécada de 80, um sistema distribuído integrava algumas dezenas, ou no máximo,algumas centenas de computadores. Com a criação da WWW aplicações distribuídas se popularizaram muito, masainda havia um grande problema relacionado a comunicação entre sistemasdiferentes, que apenas se comunicavam através de uma ponte de software. Uma solução para este problema foi a criação dos Serviços Web, pois utilizamtecnologias padrões da Internet como por exemplo, HTTP7 e XML, para provercomunicação entre um sistema e outro. Esta é a grande vantagem em se utilizarServiços Web em comparação com outras tecnologias de comunicação comoCORBA8, Java RMI9 e DCOM10, pois com estas há a necessidade em se utilizarprotocolos de comunicação e formatos de dados que ambos os sistemas entendam. Outro problema relacionado a essas tecnologias, é que sendo necessária acomunicação entre dois sistemas distintos, será necessária a criação de pontes.Ponte é um software que converte o protocolo e os dados da plataforma de partidapara um formato que a plataforma alvo entenda. A tecnologia dos Serviços Web proporciona grandes benefícios comoindependência de plataforma de hardware e software, baixo acoplamento einteroperabilidade entre aplicações. Um computador X utilizando Windows rodandouma aplicação A, consegue trocar informações com um computador Y utilizandoLinux rodando uma aplicação B, desde que estas aplicações sigam rigorosamenteas especificações de Serviços Web. Isso se deve pois os serviços são baseados noprotocolo HTTP e em especificações XML como WSDL e SOAP. Devido as vantagens citadas anteriormente é que os Serviços Web vem seconsolidando como base das novas iniciativas de negócios eletrônicos em diversosmercados.6 Disponível em < http://www.w3.org/WWW/>Acesso em: 12/03/2009.7 Hypertext Transfer Protocol.8 Common Object Request Broker Architecture (CORBA).9 Java Remote Method Invocation (RMI).10 Distributed Component Object Model (DCOM). 3
  • 4. Um Serviço Web é um software concebido para prover interoperabilidade máquina-a-máquina através de uma rede. Tem uma interface descrita em um formato processável por máquina (especificamente WSDL). Outros sistemas interagem de uma forma prescrita por sua descrição utilizando mensagens SOAP e transmitidas utilizando HTTP com uma serialização XML (BOOTH et al., 2004).3. Service Oriented Architecture (SOA) A arquitetura orientada a serviços (SOA) é uma filosofia cujo objetivo é proporcom que as funcionalidades implementadas pelas aplicações devem serdisponibilizadas na forma de serviços. Portanto SOA não é um produto e nem umobjetivo final, é um conceito arquitetural com o objetivo de construir sistemasfracamente acoplados. O fraco acoplamento é devido à forma como as aplicações são integradas,todas em nível de interface, e não em nível de implementação. Isso gera maiorflexibilidade, pois mudanças na implementação do serviço não podem afetar ocliente. Essa técnica permite com que um provedor de serviço disponibilize adescrição e localização de um serviço, para que futuramente este serviço sejaencontrado por um consumidor, como apresenta a Figura 1. Figura 1. Exemplo de Serviço Web utilizando conceito de SOA. Adaptado de Breitman (2005) 4
  • 5. Atualmente o modelo da arquitetura SOA é composto por três entidades queinteragem entre si: Consumidor, Provedor e Registrador de serviços. Provedor de serviços – Sua função é criar a descrição e publicá-la como umserviço no registrador de serviços. Também descreve a forma como consumidordeve invocar o serviço. Essas informações são representadas por um documentoXML escrito na linguagem padrão WSDL. Consumidor de serviços – Responsável por procurar um serviço, obter suadescrição e utilizar os descritores do serviço para se conectar a um provedor einvocar o serviço desejado. Registrador de serviços – Sua função é divulgar os descritores dos serviçospublicados pelos provedores. Também é de permitir que o consumidor busqueserviços em sua coleção de descrições. Utiliza o padrão UDDI para registrarinformações sobre os serviços.4. Tecnologias dos Serviços Web Para prover interoperabilidade entre plataformas distintas, são necessáriasalgumas tecnologias básicas como XML, SOAP, HTTP, WSDL e UDDI.4.1. Extensible Markup Language (XML) XML é uma meta-linguagem que estabelece um conjunto de regras quedocumentos em conformidade com XML devem obedecer. É uma linguagembaseada em marcadores que descrevem as estruturas de dados. É mais simplesque a linguagem SGML, da qual se originou, e possui algumas alternativas nãofornecidas pela linguagem HTML. XML por ser extensível e separar conteúdo de apresentação, proporciona aodesenvolvedor a possibilidade de criar seus próprios elementos de acordo com suanecessidade, preocupando-se apenas com a estruturação da informação. Para que um documento XML possa ser interpretado corretamente por umaaplicação ele deve seguir algumas regras, tornando-o assim um documento XMLbem formado. Abaixo um exemplo de XML bem formado. 5
  • 6. 1. <?xml version="1.0">2. <note>3. <to>Tove</to>4. <from>Jani</from>5. <heading>Reminder<heading>6. <body>Dont forget me this weekend!</body>7. </note> Trecho de código 4.1. Exemplo de XML bem formado • Todo documento XML deve conter o elemento root. • Valores de atributos devem vir entre “ ”. • Elementos devem estar aninhados. • Todos elementos precisam de tags de fechamento. • XML é case sensitive. Um documento XML também precisa ser validado. A validação é feita atravésde um XML Schema ou um DTD. Abaixo um exemplo de DTD e XML Schemarelacionado ao trecho de código 4.1.1. <!ELEMENT note (to, from, heading, body)>2. <!ELEMENT to (#PCDATA)>3. <!ELEMENT from (#PCDATA)>4. <!ELEMENT heading (#PCDATA)>5. <!ELEMENT body (#PCDATA)> Trecho de código 4.2. Exemplo de DTD 6
  • 7. 1. xml version="1.0"?>2. <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"3. targetNamespace="http://www.w3schools.com"4. xmlns="http://www.w3schools.com"5. elementFormDefault="qualified">6. <xs:element name="note">7. <xs:complexType>8. <xs:sequence>9. <xs:element name="to" type="xs:string"/>10. <xs:element name="from" type="xs:string"/>11. <xs:element name="heading" type="xs:string"/>12. <xs:element name="body" type="xs:string"/>13. </xs:sequence>14. </xs:complexType>15. </xs:element>16. </xs:schema> Trecho de código 4.3. Exemplo de XML Schema4.2. Simple Object Access Protocol (SOAP) Para troca de informações entre aplicações via Web, é necessário que hajaum padrão para que o destinatário entenda a mensagem. SOAP é o protocoloespecificado para Serviços Web, com a função de padronizar e estruturarinformações. SOAP utiliza XML para estruturar as informações da aplicação, como porexemplo, parâmetros de métodos, valores a serem retornados e nomes de métodosa serem invocados. Também pode indicar o endpoint da mensagem e codificarmensagens de erro caso ocorra alguma falha. Roda sobre o protocolo HTTP,significando que a comunicação se dá através da porta 80, permitindo assim, comque aplicações se comuniquem passando por firewall, evitando problemas decompatibilidade e segurança. O protocolo SOAP apresenta muitas vantagens como: • Simples e de fácil implementação. • Independente de sistema operacional. 7
  • 8. • Pode ser usado de forma anônima ou autenticado(nome/senha). • Passa por firewalls e roteadores pois roda sobre HTTP. • Protocolo robusto pois funções e dados são descritos em XML. A transmissão dos dados é feita via mensagem SOAP, que consisteem elementos obrigatórios (Envelope e Body) e elementos opcionais (Header eFault), exemplificados pela Figura 2. Figura 2. Principais elementos de uma mensagem SOAP. Adaptado de Cerami (2002) Elemento Envelope – Elemento raiz obrigatório em uma mensagem SOAP,onde são definidos os tipos de dados utilizados no documento e como processá-los.Também deve conter associado a ele o namespacehttp://www.w3.org/2001/12/soap-envelope. Caso o elemento Envelope possua outronamespace a aplicação deve gerar um erro e descartar a mensagem. Pode possuiro atributo encodingStyle que é utilizado para definir os tipos de dados usados nodocumento.O código abaixo exemplifica a construção do elemento Envelope.1. <soap:Envelope2. xmlns:soap=”http://www.w3.org/2001/12/soap-envelope”3. soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding">4. ... Informação da mensagem ...5. </soap:Envelope> Trecho de código 4.4. Exemplo do elemento Envelope. 8
  • 9. Elemento Body – Outro elemento obrigatório para todas as mensagensSOAP. É dentro deste elemento que se encontra o conteúdo da mensagem comoprocesso de invocação e parâmetros necessários (CERAMI, 2002). O exemplo aseguir mostra a estrutura de um elemento Body.1. <soap:Body>2. <x:GetSalario xmlns:x="http://www.exemplobody.com/salario">3. <x:Codigo>4. 54385. </x:Codigo>6. </x:GetSalario>7. </soap:Body> Trecho de código 4.5. Exemplo do elemento Body. Elemento Header – É um elemento opcional, que existindo deve ser oprimeiro filho do elemento Envelope. Pode ser utilizado para especificar umaassinatura digital protegendo os serviços por senha, autenticação e localização doserviço (CERAMI, 2002). Possui o atributo actor cujo objetivo é de endereçar oelemento Header a um endpoint específico. Já o atributo mustUnderstand serve paraindicar se o elemento Header deve ser interpretado ou não. Por exemplo, se oatributo mustUnderstand for igual a um o destinatário precisa reconhecer oelemento. Caso o destinatário não reconheça, o processo deve falhar.1. <soap:Header>2. <x:Trans3. xmlns:x="http://www.w3schools.com/transaction/"4. soap:actor="http://www.w3schools.com/appml/">5. <final> 149.103.220.193 </final>6. </x:Trans>7. </soap:Header> Trecho de código 4.6. Exemplo do elemento Header 9
  • 10. Elemento Fault – Responsável por tratar erros e informações de status damensagem SOAP. Caso ocorra alguma falha o elemento Fault será incluído comofilho do elemento Body. É composto por alguns sub-elementos: faultcode (identifica afalha), faultstring (descreve a falha), faultactor (quem foi causador da falha) e oelemento detail (informa o erro de aplicação relacionado ao elemento Body)(CERAMI, 2002).1. <soap:Fault>2. <soap:faultcode> 01 </soap:faultcode>3. <soap:faultstring> Serviço não encontrado </soap:faultstring>4. <soap:faultactor> 143.107.220.129 </soap:faultactor>5. <soap:detail> Falha na chamada da função getNome </soap:detail>6. </soap:Fault> Trecho de código 4.7. Exemplo do elemento Fault4.3. Web Services Description Language (WSDL) WSDL é uma linguagem de descrição escrita em XML que permite descreveros serviços disponíveis em um Serviço Web. Este documento XML incluiinformações sobre a interface das aplicações, ou seja, possui informações sobre osmétodos ou operações que o serviço realiza e informações sobre o tipo de dado damensagem de requisição e resposta. Alem disso especifica a localização do serviçodesejado. Em suma, WSDL representa um contrato entre um serviço solicitante e oprovedor deste serviço (CERAMI, 2002). Segundo Christensen (2001) WSDL separa descrições da funcionalidadeabstrata oferecida pelo serviço dos detalhes concretos da descrição do serviço. Foi criado com a combinação de duas linguagens para descrever serviços:NASSL (Network Application Service Specification Language) da IBM e SDL (ServiceDescription Language) da Microsoft. Como visto anteriormente, um documento WSDL é uma gramática XML quedescreve serviços. Os principais elementos deste documento são: definitions, types,message, portType, binding e service. Elemento definitions – É o elemento raiz de um documento WSDL. Tem asfunções de definir o nome do serviço Web, declarar múltiplos namespaces e conter 10
  • 11. todos os elementos de serviço descritos (CERAMI, 2002). A seguir um exemplo doelemento definitions.1. <definitions name =" Exemplo "2. targetNamespace =" http: // www . paulovitor . com.br / wsdl / Exemplo . wsdl"3. xmlns =" http: // schemas . xmlsoap .org/ wsdl /"4. xmlns:soap =" http: // schemas . xmlsoap . org / wsdl / soap /"5. xmlns:tns =" http http: // www . paulovitor . com.br / wsdl / Exemplo . wsdl "6. xmlns:xsd =" http: // www.w3. org /2001/ XMLSchema ">7. ...8. </ definitions > Trecho de código 4.8. Exemplo do elemento definitions Elemento types – Define os tipos de dados que são utilizados pelo ServiçoWeb. Não é vinculado exclusivamente a um determinado sistema para tipar dados,mas utiliza o XML Schema como padrão para definição de tipos de dados (CERAMI,2002). Elemento message – Define elementos de dados de uma determinadaoperação, separando mensagens de requisição de mensagens de resposta. Amensagem de resposta pode conter os tipos de dados ou valores retornados. Já amensagem de requisição informa os parâmetros e os tipos dos dados, comoexemplificado abaixo.1. <message name="multiplicacaoRequest">2. <part name="x" type="xsd:float"/>3. <part name="y" type="xsd:float"/>4. </message>5. <message name="multiplicacaoResponse">6. <part name="multiplicacaoReturn" type="xsd:float"/>7. </message> Trecho de código 4.9. Exemplo do elemento message 11
  • 12. Elemento portType – Elemento que define um Serviço Web, as operaçõesdisponibilizadas pelo serviço e as mensagens envolvidas. Uma mensagem depedido e resposta pode ser combinada em uma única mensagem (CERAMI, 2002).1. <portType name =" Exemplo">2. <operation name="multiplicacao" parameterOrder="x y”>3. <input message="impl:multiplicacaoRequest"4. name="multiplicacaoRequest"/>5. <output message="impl:multiplicacaoResponse"6. name="multiplicacaoResponse"/>7. </operation>8. </portType > Trecho de código 4.10. Exemplo do elemento portType Elemento binding – Elemento que descreve a forma de acesso ao serviçoatravés do protocolo SOAP. O documento abaixo exemplifica a construção de umelemento binding. 1. <binding name="Exemplo" type="impl:ExemploImpl"> 2. <soap:binding style="rpc“ transport="http://schemas.xmlsoap.org/soap/http"/> 3. <operation name="multiplicacao"> 4. <soap:operation soapAction=""/> 5. <input name="multiplicacaoRequest"> 6. <soap:body encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" 7. namespace="http://DefaultNamespace" use="encoded"/> 8. </input> 9. <output name="multiplicacaoResponse">10. <soap:body encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"11. namespace="http://127.0.0.1:8080/arq/ExemploImpl.jws" use="encoded"/>12. </output>13. </operation>14. </ binding > Trecho de código 4.11. Exemplo do elemento binding 12
  • 13. Elemento service – Elemento que define o endereço para invocar o serviçoespecificado. Tem uma URL para invocar um serviço SOAP.1. <service name="Exemplo">2. <port binding="impl:Exemplo" name="ExemploImpl">3. <soap:address location="http://127.0.0.1:8080/arq/ExemploServicoImpl.jws"/>4. </port>5. </service> Trecho de código 4.12. Exemplo do elemento service4.4. Universal Description, Discovery and Integration (UDDI) É um protocolo utilizado para especificar mecanismos baseados em padrõespara classificar, catalogar e administrar serviços, fazendo com que eles sejamdescobertos por outras aplicações. Isso é possível pois os dados, que sãodocumentos XML, ficam armazenados em diretórios de serviços (CERAMI, 2002). De maneira geral, o registro de serviços UDDI possui dois tipos de cliente. Umé o provedor de serviços, que deseja publicar seus serviços e interfaces. O outro é oconsumidor de serviços, que deseja obter o serviço e se conectar a ele. Segundo Cerami (2002), os dados armazenados dentro do UDDI sãodivididos em três categorias: Páginas brancas – Categoria que inclui informações gerais sobre umaempresa específica, por exemplo, nome comercial, descrição e endereço. Páginas amarelas – Classificam os dados do serviço oferecidos seguindonormas taxonômicas. Páginas verdes – Possui informações técnicas sobre um Serviço Web, como,um ponteiro para uma especificação externa e um endereço para invocar o serviço. Além de permitir a publicação de seus serviços, UDDI também permite apublicação de especificações e taxonomias através de uma entidade chamadatModel. É uma estrutura que representa de forma genérica um serviço registrado noUDDI. Deve conter ponteiros para especificações externas. Ao registrar um serviço como um tModel um identificador único será dado aotModel registrado. Através do identificador, um negócio pode especificar que um ouvários de seus serviços estão em conformidade com a especificação do tModel. UmtModel é composto por 8 elementos: 13
  • 14. tModelKey – Chave obrigatória que identifica um tModel. authorizedName – Contem o nome da pessoa que publicou o tModel. operator – Contem o nome do operador que mantém a copia mestre dotModel. description – Descrição do tModel. name – Nome do tModel. overviewDoc – Referencia a descrição externa ao tModel, por exemplo, umdocumento WSDL localizado no servidor do serviço. identifierBag – Registram números de identificação para um tModel. categoryBag – Associam taxonomias a tModels.5. Conclusão Podemos concluir que o Serviço Web é uma ótima solução para integração desistemas, pois apresenta vantagens como independência de plataforma, baixoacoplamento e provê interoperabilidade entre aplicações. Outra vantagem destatecnologia é o seu baixo custo, pois se baseia em padrões abertos da Internet. Porfim concluímos que apesar de todas estas vantagens ainda encontramos algunsproblemas como limitação na linguagem de descrição e atualização de linksquebrados.Referências Bibliográficas BRAY, T.; PAOLI, J.; MALER, E.; YERGEAU, F. Extensible Markup Language(XML) 1.0 (Fourth Edition), Agosto 2006. Disponível emhttp://www.w3.org/TR/2006/REC-xml-20060816/#sec-intro BOOTH, D. et al. Web Services Architecture, Fevereiro 2004. Disponível emhttp://www.w3.org/TR/2004/NOTE-ws-arch-20040211/ CERAMI, E. Web Services Essentials. Sebastopol, CA, USA: O’Reilly &Associates,2002. 14