A Estrutura de um Web Service

Transcrição

1 A Estrutura de um Web Service Paulo Vitor Antonini Orlandin Resumo 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. Palavras chave: Serviços Web. WSDL. UDDI. XML. Web Service. SOAP. 1. Introdução Com a grande necessidade de integração entre sistemas computacionais que na maioria das vezes são heterogêneos, e que normalmente não se comunicam por falta 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 a utilização do Simple Object Access Protocol (SOAP) 1 se torna indispensável. Graças a esta tecnologia a troca de informações entre novas e antigas aplicações se torna possível, bem como integração entre aplicações desenvolvidas em plataformas diferentes. Cada aplicação pode ter sua própria linguagem, que é traduzida para o formato XML 2, formato em que as mensagens são enviadas e recebidas (BOOTH et al., 2004). Um serviço que esteja disponível na Internet se comunicando de forma padronizada utilizando XML, provendo interoperabilidade entre sistemas e apoiandose sobre os protocolos da Internet é um Serviço Web (BOOTH et al., 2004). 1 Service Oriented Architecture (SOA) 2 Disponível em < Acesso em: 25/02/

2 As mensagens recebidas e enviadas são estruturadas como documentos XML, que são encapsulados pelo protocolo SOAP 3 e transportados via HTTP. A linguagem WSDL 4 é utilizada para descrever os serviços, que são: publicados, procurados, descobertos e divulgados utilizando o protocolo UDDI 5 (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 de software cujo princípio fundamental é que as funcionalidades implementadas pelas aplicações devem ser disponibilizadas na forma de serviços. É um paradigma de desenvolvimento 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 em busca de interoperabilidade para suas aplicações. Além disso, os Serviços Web podem trazer eficiência na comunicação interna de uma empresa e assim agilizando os processos da mesma. 3 Disponível em < Acesso em: 25/02/ Disponível em < Acesso em: 25/02/ Disponível em < Acesso em: 27/02/

3 2. Serviços Web Antes da criação da World Wide Web (WWW 6 ) por Tim Berners-Lee no fim da dé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, mas ainda havia um grande problema relacionado a comunicação entre sistemas diferentes, 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 utilizam tecnologias padrões da Internet como por exemplo, HTTP 7 e XML, para prover comunicação entre um sistema e outro. Esta é a grande vantagem em se utilizar Serviços Web em comparação com outras tecnologias de comunicação como CORBA 8, Java RMI 9 e DCOM 10, pois com estas há a necessidade em se utilizar protocolos de comunicação e formatos de dados que ambos os sistemas entendam. Outro problema relacionado a essas tecnologias, é que sendo necessária a comunicaçã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 partida para um formato que a plataforma alvo entenda. A tecnologia dos Serviços Web proporciona grandes benefícios como independência de plataforma de hardware e software, baixo acoplamento e interoperabilidade entre aplicações. Um computador X utilizando Windows rodando uma aplicação A, consegue trocar informações com um computador Y utilizando Linux rodando uma aplicação B, desde que estas aplicações sigam rigorosamente as especificações de Serviços Web. Isso se deve pois os serviços são baseados no protocolo HTTP e em especificações XML como WSDL e SOAP. Devido as vantagens citadas anteriormente é que os Serviços Web vem se consolidando como base das novas iniciativas de negócios eletrônicos em diversos mercados. 6 Disponível em < em: 12/03/ 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 é propor com que as funcionalidades implementadas pelas aplicações devem ser disponibilizadas na forma de serviços. Portanto SOA não é um produto e nem um objetivo final, é um conceito arquitetural com o objetivo de construir sistemas fracamente 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 maior flexibilidade, pois mudanças na implementação do serviço não podem afetar o cliente. Essa técnica permite com que um provedor de serviço disponibilize a descrição e localização de um serviço, para que futuramente este serviço seja encontrado 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 que interagem entre si: Consumidor, Provedor e Registrador de serviços. Provedor de serviços Sua função é criar a descrição e publicá-la como um serviço no registrador de serviços. Também descreve a forma como consumidor deve invocar o serviço. Essas informações são representadas por um documento XML escrito na linguagem padrão WSDL. Consumidor de serviços Responsável por procurar um serviço, obter sua descrição e utilizar os descritores do serviço para se conectar a um provedor e invocar o serviço desejado. Registrador de serviços Sua função é divulgar os descritores dos serviços publicados pelos provedores. Também é de permitir que o consumidor busque serviços em sua coleção de descrições. Utiliza o padrão UDDI para registrar informações sobre os serviços. 4. Tecnologias dos Serviços Web Para prover interoperabilidade entre plataformas distintas, são necessárias algumas tecnologias básicas como XML, SOAP, HTTP, WSDL e UDDI Extensible Markup Language (XML) XML é uma meta-linguagem que estabelece um conjunto de regras que documentos em conformidade com XML devem obedecer. É uma linguagem baseada em marcadores que descrevem as estruturas de dados. É mais simples que a linguagem SGML, da qual se originou, e possui algumas alternativas não fornecidas pela linguagem HTML. XML por ser extensível e separar conteúdo de apresentação, proporciona ao desenvolvedor a possibilidade de criar seus próprios elementos de acordo com sua necessidade, preocupando-se apenas com a estruturação da informação. Para que um documento XML possa ser interpretado corretamente por uma aplicação ele deve seguir algumas regras, tornando-o assim um documento XML bem 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>don't 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és de um XML Schema ou um DTD. Abaixo um exemplo de DTD e XML Schema relacionado ao trecho de código <!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=" 3. targetnamespace=" 4. xmlns=" 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 Schema 4.2. Simple Object Access Protocol (SOAP) Para troca de informações entre aplicações via Web, é necessário que haja um padrão para que o destinatário entenda a mensagem. SOAP é o protocolo especificado para Serviços Web, com a função de padronizar e estruturar informações. SOAP utiliza XML para estruturar as informações da aplicação, como por exemplo, parâmetros de métodos, valores a serem retornados e nomes de métodos a serem invocados. Também pode indicar o endpoint da mensagem e codificar mensagens 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, com que aplicações se comuniquem passando por firewall, evitando problemas de compatibilidade 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 consiste em elementos obrigatórios (Envelope e Body) e elementos opcionais (Header e Fault), 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 namespace Caso o elemento Envelope possua outro namespace a aplicação deve gerar um erro e descartar a mensagem. Pode possuir o atributo encodingstyle que é utilizado para definir os tipos de dados usados no documento.o código abaixo exemplifica a construção do elemento Envelope. 1. <soap:envelope 2. xmlns:soap= 3. soap:encodingstyle=" Informação da mensagem </soap:envelope> Trecho de código 4.4. Exemplo do elemento Envelope. 8

9 Elemento Body Outro elemento obrigatório para todas as mensagens SOAP. É dentro deste elemento que se encontra o conteúdo da mensagem como processo de invocação e parâmetros necessários (CERAMI, 2002). O exemplo a seguir mostra a estrutura de um elemento Body. 1. <soap:body> 2. <x:getsalario xmlns:x=" 3. <x:codigo> </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 o primeiro filho do elemento Envelope. Pode ser utilizado para especificar uma assinatura digital protegendo os serviços por senha, autenticação e localização do serviço (CERAMI, 2002). Possui o atributo actor cujo objetivo é de endereçar o elemento Header a um endpoint específico. Já o atributo mustunderstand serve para indicar se o elemento Header deve ser interpretado ou não. Por exemplo, se o atributo mustunderstand for igual a um o destinatário precisa reconhecer o elemento. Caso o destinatário não reconheça, o processo deve falhar. 1. <soap:header> 2. <x:trans 3. xmlns:x=" 4. soap:actor=" 5. <final> </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 da mensagem SOAP. Caso ocorra alguma falha o elemento Fault será incluído como filho do elemento Body. É composto por alguns sub-elementos: faultcode (identifica a falha), faultstring (descreve a falha), faultactor (quem foi causador da falha) e o elemento 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> </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 Fault 4.3. Web Services Description Language (WSDL) WSDL é uma linguagem de descrição escrita em XML que permite descrever os serviços disponíveis em um Serviço Web. Este documento XML inclui informações sobre a interface das aplicações, ou seja, possui informações sobre os métodos ou operações que o serviço realiza e informações sobre o tipo de dado da mensagem de requisição e resposta. Alem disso especifica a localização do serviço desejado. Em suma, WSDL representa um contrato entre um serviço solicitante e o provedor deste serviço (CERAMI, 2002). Segundo Christensen (2001) WSDL separa descrições da funcionalidade abstrata 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 (Service Description Language) da Microsoft. Como visto anteriormente, um documento WSDL é uma gramática XML que descreve 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 as funçõ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 do elemento 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: // org /2001/ XMLSchema "> </ definitions > Trecho de código 4.8. Exemplo do elemento definitions Elemento types Define os tipos de dados que são utilizados pelo Serviço Web. 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 determinada operação, separando mensagens de requisição de mensagens de resposta. A mensagem de resposta pode conter os tipos de dados ou valores retornados. Já a mensagem de requisição informa os parâmetros e os tipos dos dados, como exemplificado 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ções disponibilizadas pelo serviço e as mensagens envolvidas. Uma mensagem de pedido 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 Exemplo do elemento porttype Elemento binding Elemento que descreve a forma de acesso ao serviço através do protocolo SOAP. O documento abaixo exemplifica a construção de um elemento binding. 1. <binding name="exemplo" type="impl:exemploimpl"> 2. <soap:binding style="rpc transport=" 3. <operation name="multiplicacao"> 4. <soap:operation soapaction=""/> 5. <input name="multiplicacaorequest"> 6. <soap:body encodingstyle=" 7. namespace=" use="encoded"/> 8. </input> 9. <output name="multiplicacaoresponse"> 10. <soap:body encodingstyle=" 11. namespace=" use="encoded"/> 12. </output> 13. </operation> 14. </ binding > Trecho de código Exemplo do elemento binding 12

13 Elemento service Elemento que define o endereço para invocar o serviço especificado. Tem uma URL para invocar um serviço SOAP. 1. <service name="exemplo"> 2. <port binding="impl:exemplo" name="exemploimpl"> 3. <soap:address location=" 4. </port> 5. </service> Trecho de código Exemplo do elemento service 4.4. Universal Description, Discovery and Integration (UDDI) É um protocolo utilizado para especificar mecanismos baseados em padrões para classificar, catalogar e administrar serviços, fazendo com que eles sejam descobertos por outras aplicações. Isso é possível pois os dados, que são documentos 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 é o consumidor de serviços, que deseja obter o serviço e se conectar a ele. Segundo Cerami (2002), os dados armazenados dentro do UDDI são divididos em três categorias: Páginas brancas Categoria que inclui informações gerais sobre uma empresa específica, por exemplo, nome comercial, descrição e endereço. Páginas amarelas Classificam os dados do serviço oferecidos seguindo normas 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 a publicação de especificações e taxonomias através de uma entidade chamada tmodel. É uma estrutura que representa de forma genérica um serviço registrado no UDDI. Deve conter ponteiros para especificações externas. Ao registrar um serviço como um tmodel um identificador único será dado ao tmodel registrado. Através do identificador, um negócio pode especificar que um ou vários de seus serviços estão em conformidade com a especificação do tmodel. Um tmodel é 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 do tmodel. description Descrição do tmodel. name Nome do tmodel. overviewdoc Referencia a descrição externa ao tmodel, por exemplo, um documento 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 de sistemas, pois apresenta vantagens como independência de plataforma, baixo acoplamento e provê interoperabilidade entre aplicações. Outra vantagem desta tecnologia é o seu baixo custo, pois se baseia em padrões abertos da Internet. Por fim concluímos que apesar de todas estas vantagens ainda encontramos alguns problemas como limitação na linguagem de descrição e atualização de links quebrados. Referências Bibliográficas BRAY, T.; PAOLI, J.; MALER, E.; YERGEAU, F. Extensible Markup Language (XML) 1.0 (Fourth Edition), Agosto Disponível em BOOTH, D. et al. Web Services Architecture, Fevereiro Disponível em CERAMI, E. Web Services Essentials. Sebastopol, CA, USA: O Reilly & Associates,