Web service – Wikipédia, a enciclopédia livre

Este artigo ou secção contém uma lista de referências no fim do texto, mas as suas fontes não são claras porque não são citadas no corpo do artigo, o que compromete a confiabilidade das informações. Ajude a melhorar este artigo inserindo citações no corpo do artigo. (Janeiro de 2009)

Web Service é uma solução utilizada na integração de sistemas e na comunicação entre aplicações diferentes. Com esta tecnologia é possível que novas aplicações possam interagir com aquelas que já existem e que sistemas desenvolvidos em plataformas diferentes sejam compatíveis. Os Web Services são componentes que permitem às aplicações enviar e receber dados. Cada aplicação pode ter a sua própria "linguagem", que é traduzida para uma linguagem universal, um formato intermediário como XML, JSON, CSV, etc.

Para as empresas, os Web Services podem trazer agilidade para os processos e eficiência na comunicação entre cadeias de produção ou de logística. Toda e qualquer comunicação entre sistemas passa a ser dinâmica e principalmente segura, pois não há intervenção humana.

Essencialmente, o Web Service faz com que os recursos da aplicação do software estejam disponíveis sobre a rede de forma normalizada. Outras tecnologias fazem a mesma coisa; por exemplo, os browsers da Internet acessam as páginas Web disponíveis usando por norma as tecnologias da Internet, HTTP e HTML. No entanto, estas tecnologias não são bem sucedidas na comunicação e integração de aplicações. Existe uma grande motivação sobre a tecnologia Web Service pois possibilita que diferentes aplicações comuniquem-se entre si e utilizem recursos diferentes.

Utilizando a tecnologia Web Service, uma aplicação pode invocar outra para efetuar tarefas simples ou complexas mesmo que as duas aplicações estejam em diferentes sistemas e escritas em linguagens diferentes. Por outras palavras, os Web Services fazem com que os seus recursos estejam disponíveis para que qualquer aplicação cliente possa operar e extrair os recursos fornecidos pelo Web Service.

Os Web Services são identificados por um URI (Uniform Resource Identifier), descritos e definidos usando XML (Extensible Markup Language). Um dos motivos que tornam os Web Services atrativos é o fato deste modelo ser baseado em tecnologias standards, em particular XML e HTTP (Hypertext Transfer Protocol). Os Web Services são utilizados para disponibilizar serviços interativos na Web, podendo ser acessados por outras aplicações usando, por exemplo, o protocolo SOAP (Simple Object Access Protocol).

O objetivo dos Web Services é a comunicação de aplicações através da Internet. Esta comunicação é realizada com intuito de facilitar a EAI (Enterprise Application Integration) que significa a integração das aplicações de uma empresa, ou seja, interoperabilidade entre a informação que circula numa organização nas diferentes aplicações como, por exemplo, o comércio electrónico com os seus clientes e seus fornecedores. Esta interação constitui o sistema de informação de uma empresa. E para além da interoperabilidade entre as aplicações, a EAI permite definir um workflow entre as aplicações e pode constituir uma alternativa aos ERP (Enterprise Resource Planning). Com um workflow é possível otimizar e controlar processos e tarefas de uma determinada organização.

A W3C, OASIS são as instituições responsáveis pela padronização dos Web Services. Empresas como IBM e Microsoft, duas das maiores do setor de tecnologia, apoiam o desenvolvimento deste padrão.

Segundo o W3C (World Wide Web Consortium) um Web Service define-se como: um sistema de software projectado para suportar a interoperabilidade entre máquinas sobre rede.

Tem uma relação descritiva num formato machine-processable, especificamente WSDL (Webservice Description Language).

Outros sistemas interagem com o Web Service usando as mensagens SOAP, tipicamente sobre HTTP com XML na junção com outros standards da Web.

As bases para a construção de um Web service são os padrões XML e SOAP. O transporte dos dados é realizado normalmente via protocolo HTTP ou HTTPS para conexões seguras (o padrão não determina o protocolo de transporte). Os dados são transferidos no formato XML, encapsulados pelo protocolo SOAP. Também é bastante comum usar o protocolo REST (Representational transfer protocol), para transferir o estado do dado para a aplicação.

Muitas empresas temiam, no passado, prover funcionalidades na Internet devido ao medo de expor seus dados. Mas com advento dos Web Services elas podem publicar serviços de forma simples e que são totalmente isolados da base de dados.

A segurança dos Web Services é um dos pontos fracos desta tecnologia. O problema não é a falta de mecanismos de segurança mas sim a falta de consenso em qual deve ser o mecanismo a ser adaptado pela tecnologia Web Service. As questões mais relevantes na segurança são as seguintes:

• Autenticidade (ter a certeza que uma transação do Web Service ocorreu entre o servidor e seu cliente;
• Confidencialidade (todas as mensagens trocadas entre o servidor e o cliente não são interceptadas por uma pessoa não autorizada);
• Integridade (as mensagens enviadas tanto pelo servidor ao cliente, como o contrário, devem permanecer inalteradas).

A seguir, descrevem-se os principais mecanismos de segurança.

O SSL (Secure Socket Layer) [Netscape 1996] quando aplicado a pequenos dispositivos oferece autenticação, integridade de dados e privacidade de serviços. Assim, tornou-se possível enviar informação confidencial utilizando um mecanismo de segurança SSL sob HTTP também conhecido como HTTPS (Hypertext Transfer Protocol Secure). Este mecanismo protege informações confidenciais e é fácil de ser configurado. Tem como desvantagem ser mais lento do que as transações HTTP não cifradas pelo que não é adequado para taxas de transferências de dados elevadas.

Por ser um mecanismo de proteção no nível de transporte, apresenta restrições para ser aplicado em aplicações webservices, pois o SSL não permite criptografia de parte da informação nem o uso de sessões seguras entre mais de duas partes, uma vez que seu funcionamento se baseia em uma arquitetura de transporte fim-a-fim.

A XML Signature [IETF e W3C 2000] é uma iniciativa conjunta da IETF (Internet Engineering Task Force) e do W3C para especificar uma sintaxe XML e regras de processamento para criação e representação de assinatura digital. As vantagens na utilização da XML Signature, ao contrário de outras normas de assinaturas digitais, estão baseadas na independência da linguagem de programação, fácil interpretação humana e independência do fabricante. Esta tecnologia também permite assinar digitalmente subconjuntos de um documento XML.

A Criptografia XML, também conhecida como XML-Enc, é uma especificação, regida por uma recomendação do W3C, que define como criptografar o conteúdo de um elemento XML.

Embora a criptografia XML pode ser usada para criptografar qualquer tipo de dados, não deixa de ser conhecido como "Criptografia XML", porque um elemento XML (um EncryptedData ou EncryptedKey elemento) contém ou refere-se ao texto cifrado, informações de codificação, e algoritmos.

Tanto a XML Signature quanto a XML Encryption usam o elemento KeyInfo, que aparece como o filho de um elemento SignedInfo, EncryptedData ou EncryptedKey, e fornece informações a um destinatário sobre qual material de chave usar na validação de uma assinatura ou na descriptografia de dados criptografados.

O elemento KeyInfo é opcional: pode ser anexado à mensagem ou ser entregue por meio de um canal seguro.

A Criptografia XML é diferente e não está relacionada à Segurança da Camada de Transporte, que é usada para enviar mensagens criptografadas (incluindo conteúdo xml, criptografado ou não) pela Internet.

Foi relatado que esta especificação tem graves preocupações de segurança.

O WS-Security (Web Services Security) é uma iniciativa conjunta de empresas como Microsoft, IBM e Verisign destinada ao uso da XML-Signature e da XML-Encryption para fornecer segurança às mensagens SOAP. O WS-Security é um esforço destinado a fazer com que os Web Services trabalhem melhor em um ambiente global. O WS-Security também inclui alguns importantes componentes como encaminhamento, confiança e tratamento de transações.

Definição e manutenção de uma estrutura padrão baseada em XML para criar e trocar informações de segurança entre parceiros on-line

Visão geral

O SAML (Security Assertion Markup Language), desenvolvido pelo Comitê Técnico de Serviços de Segurança do OASIS, é uma estrutura baseada em XML para comunicar informações de autenticação, autorização e atributo do usuário. Como o próprio nome sugere, o SAML permite que as entidades comerciais façam afirmações sobre a identidade, os atributos e os direitos de um assunto (uma entidade que geralmente é um usuário humano) para outras entidades, como uma empresa parceira ou outro aplicativo corporativo.

Se você é um gerente procurando por uma visão geral de alto nível do SAML, a Visão Geral Executiva é recomendada. Se você estiver procurando por uma introdução técnica aos conceitos e recursos de SAML, recomenda-se começar com a Visão geral técnica . Informações técnicas adicionais, incluindo o conjunto completo de especificações SAML , podem ser encontradas na base de conhecimento em saml.xml.org.

Apesar da sua grande popularidade ^{[carece de fontes?]} e relativa simplicidade ^{[carece de fontes?]}, o SOAP tem várias limitações, que por sua vez afetam os Web Services diretamente, por dependerem de tais recursos...

As limitações são descritas em seguida:

• Segurança e privacidade — nenhuma das versões do SOAP define qualquer tipo de segurança. Isto é devido ao SOAP utilizar HTTP, mas para implementar mecanismos de segurança no nível de transporte pode utilizar o protocolo SSL no HTTP (também conhecido como HTTPS) para garantir a confidencialidade, a integridade e a autenticação do cliente, do servidor e da comunicação cifrada. Como não existe um suporte para segurança, que inclui a privacidade, nas normas que compõem os Web Services, tem levado cada projeto a procurar diferentes soluções para resolver o problema da segurança o que se torna incompatível com a promessa de implementar uma normalização a nível global.
• Mensagens e encaminhamento — para suportar as funcionalidades das mensagens assíncronas tradicionais
• Qualidade de serviço e confiabilidade — para garantir tempos de resposta e detectar exceções
• Processamento transacional — para suportar comunicação transacional, para associar essa comunicação transacional com as transações locais e para participar em transações distribuídas
• Gestão — para controlar o estado e comportamento dos Web Services
• Desempenho — para otimizar a execução dos Web Services que tem implicações ao nível do desenho das aplicações, chamadas remotas, características da rede e armazenamento/processamento dos documentos
• Interoperabilidade — suportar a interoperação sem problemas é o grande objetivo dos Web Services e do SOAP, ou seja, fornecerem uma plataforma de integração entre aplicações e diferentes linguagens e implementados em qualquer sistema operacional.

Assim, esta tecnologia seria uma tecnologia normalizada, mas, no entanto, existem algumas incompatibilidades entre os WSDL´s disponibilizados entre os diferentes fornecedores. A exemplo da especificação, ao que refere-se ao binding, podem ser implementados de diferentes maneiras, causando um conflito de como fazer a interpretação. Alguns fazem tal qual a especificação, relacionando e declarando todos os métodos e objetos complexos de forma explícita, enquanto outros fornecedores não o fazem desta forma, tornando-os assim, incompatíveis.

Muitas pessoas consideram que os Web services corrigem um grande problema da informática: a falta de integração de sistemas.

Os Web services permitem que a integração de sistemas seja realizada de maneira compreensível, reutilizável e padronizada.

É uma tentativa de organizar um cenário cercado por uma grande variedade de diferentes aplicativos, fornecedores e plataformas.

Para a representação e estruturação dos dados nas mensagens recebidas/enviadas é utilizado o XML . As chamadas às operações, incluindo os parâmetros de entrada/saída, são codificadas no protocolo SOAP. Os serviços (operações, mensagens, parâmetros, etc.) são descritos usando a linguagem WSDL. O processo de publicação/pesquisa/descoberta de Web Services utiliza o protocolo UDDI.

Extensible Markup Language (XML) é a base em que os Web Services são construídos. O XML fornece a descrição, o armazenamento, o formato da transmissão para trocar os dados através dos Web Services e também para criar tecnologias Web Services para a troca dos dados.

A sintaxe de XML usada nas tecnologias dos Web Services especifica como os dados são representados genericamente, define como e com que qualidades de serviço os dados são transmitidos, pormenoriza como os serviços são publicados e descobertos. Os Web Services decodificam as várias partes de XML para interagir com as várias aplicações.

A Representational State Transfer (REST), em português Transferência de Estado Representacional, é um estilo de arquitetura que define um conjunto de restrições e propriedades baseados em HTTP. Web Services que obedecem ao estilo arquitetural REST, ou web services RESTful, fornecem interoperabilidade entre sistemas de computadores na Internet. As webs service compatíveis com REST permitem que os sistemas solicitantes acessem e manipulem representações textuais de recursos da Web usando um conjunto uniforme e predefinido de operações sem estado. Outros tipos de web services, como web services SOAP, expõem seus próprios conjuntos arbitrários de operações.

O SOAP (Simple Object Access Protocol) baseia-se numa invocação remota de um método e para tal necessita especificar o endereço do componente, o nome do método e os argumentos para esse método. Estes dados são formatados em XML com determinadas regras e enviados normalmente por HTTP para esse componente. Não define ou impõe qualquer semântica, quer seja o modelo de programação, quer seja a semântica específica da implementação. Este aspecto é extremamente importante, pois permite que quer o serviço, quer o cliente que invoca o serviço sejam aplicações desenvolvidas sobre diferentes linguagens de programação. Por esta razão, o SOAP tornou-se uma norma aceita para se utilizar com Web Services, uma tecnologia construída com base em XML e HTTP. Desta forma, pretende-se garantir a interoperabilidade e intercomunicação entre diferentes sistemas, através da utilização da linguagem XML e do mecanismo de transporte HTTP ou outro como, por exemplo, SMTP. O SOAP permite que os documentos XML de envio e de recepção sobre a Web suportem um protocolo comum de transferência de dados para uma comunicação de rede eficaz, ou seja, o SOAP providencia o transporte de dados para os Web Services.^[1]

Em relação a Web, o SOAP é um protocolo de RPC que funciona sobre HTTP (ou SMTP, ou outro) de forma a ultrapassar as restrições de segurança/firewalls normalmente impostas aos sistemas clássicos de RPC (RMI, DCOM, CORBA/IIOP) suportando mensagens XML. Em vez de usar HTTP para pedir uma página HTML para ser visualizada num browser, o SOAP envia uma mensagem de XML através do pedido HTTP e recebe uma resposta, se existir, através da resposta do HTTP. Para assegurar corretamente a transmissão da mensagem de XML, o servidor de HTTP, tais como Apache ou IIS (Microsoft Internet Information Server), recebe mensagens SOAP e deve validar e compreender o formato do documento XML definido na especificação SOAP v1.1.

É a sigla de Web Services Description Language, padrão baseado em XML para descrever o serviço como no COM, onde ele traz os métodos do Web Service. Funciona como uma espécie de "TypeLibrary" do Web Service, além de ser usado para a validação das chamadas dos métodos.

O WSDL é uma especificação desenvolvida pelo W3C.

O WSDL é extensível para permitir a descrição dos serviços e suas mensagens, independentemente dos formatos de mensagem e dos protocolos de rede que sejam usados. No entanto, é comum usar-se o MIME (Multipurpose Internet Mail Extensions) e o HTtp://SOAP.

O WSDL descreve os serviços disponibilizados à rede através de uma semântica XML, este providencia a documentação necessária para se chamar um sistema distribuído e o procedimento necessário para que esta comunicação se estabeleça. Enquanto que o SOAP especifica a comunicação entre um cliente e um servidor, o WSDL descreve os serviços oferecidos.

A versão atual é 2.0; a versão 1.1 não foi endossada pelo W3C. A WSDL 1.2 foi renomeada para 2.0 e aceita todos os métodos de requisição HTTP (não apenas GET e POST).

Protocolo desenvolvido para a organização e registro de Web Services.

O UDDI (Universal Description Discovery and Integration) é uma iniciativa em desenvolvimento no âmbito do consórcio industrial UDDI promovido originalmente pela IBM, Microsoft e Arriba, com objetivo de acelerar a interoperabilidade e utilização dos Web Services, pela proposta de um serviço de registro de nomes de organizações e de descrição do serviço. UDDI nada mais é do que um serviço de diretório onde empresas podem registrar (publicar) e buscar (descobrir) por serviços Web (Web Services).

Um registro UDDI contém três tipos de informação:

• informações gerais de cada organização, tais como o nome, endereço e contatos;
• informações de organizações e serviços por categorias de negócios;
• informações técnicas sobre os serviços providenciados pelas organizações.

O UDDI providencia três funções principais, conhecidas como publicação, descoberta e ligação:

1) publicação: permite que uma organização divulgue o(s) seu(s) serviço(s);

2) descoberta: permite que o cliente do serviço procure e encontre um determinado serviço;

3) ligação (bind): permite que o cliente do serviço possa estabelecer a ligação e interagir com o serviço.

Um serviço de registro UDDI é um Web Service que gerencia informação sobre provedores, implementações e metadados de serviços. Provedores de serviços podem utilizar UDDI para publicar os serviços que eles oferecem. Usuários de serviços podem usar UDDI para descobrir serviços que lhes interessem e obter os metadados necessários para utilizar esses serviços podem ter três partes:

·        "páginas brancas" descrevem a companhia: nome, endereço, contatos, etc.

·        "páginas amarelas" incluem as categorias, baseada em taxonomias padrões.

·        "páginas verdes" descrevem a interface para o serviço em nível de detalhe suficiente para se escrever uma aplicação que use o Web service.

A especificação UDDI define:

·        APIs SOAP utilizadas para publicar e obter informações de um registro UDDI

·        Esquemas XML do modelo de dados do registro e do formato das mensagens SOAP

·        Definições WSDL das APIs SOAP

·        Definições de registro UDDI (modelos técnicos - tModels) de diversos sistemas de identificação e categorização, que podem ser utilizados para identificar e categorizar registros UDDI^[2]

É o consórcio que garante a integração entre os Web Services para garantir sempre que os Web Services possam "conversar entre si".

O sucesso que os Web Services possam vir a apresentar passa necessariamente pela vontade da indústria, pela partilha e abertura dos processos de normalização e das próprias especificações daí resultantes. Parte significativa desse processo tem sido desenvolvida no âmbito do W3C. No entanto, dever-se-á também referir outros esforços e consórcios que têm vindo a ser desenvolvidos, designadamente o UDDI, o ebXML, ou o XML/EDI. Por exemplo, o ebXML é um esforço patrocinado pela UN/CEFACT e pela OASIS, cujo objetivo é a produção de um conjunto de especificações para permitir colaborações de negócio eletrônico. O standard ebXML pode ser visto como uma extensão às funcionalidades de descrição, publicação e descoberta de serviços (definidas no âmbito do UDDI), ao tratar os seguintes aspectos: como especificar os processos de negócio; como identificar os Web Services participantes e respectivas colaborações; ou, que padrões de negociação existem na colaboração entre os participantes. Estes aspectos, são tratados nomeadamente nas seguintes especificações:

1) Esquemas para especificação de processos de negócio, BPSS (business process specification schema);

2) Acordos de protocolos de colaboração, CPA (collaboration protocol agreement);

3) Ou perfis de protocolos de colaboração, CPP (collaboration protocol profile).

As principais empresas, para além de promoverem e participarem ativamente nos vários consórcios de normalização, têm vindo a incorporar nas suas próprias infraestruturas de desenvolvimento e suporte de aplicações implementações das normas ligadas aos Web Services. Entre outras, merece referência a plataforma da Microsoft, ".Net", da Sun, "Java ONE (Open Net Environment)", da Hewlett-Packard, "e-speak" e da IBM, "IBM Web Services".

Só o futuro dirá quem tem razão: se os céticos ou conservadores, se os que arriscam e concretizam a sua visão. Com o conceito dos Web Services talvez o mais importante nem seja a tecnologia em si, mas toda uma discussão à volta dos fatores político-econômicos que este paradigma poderá suscitar, bem como os modelos de negócio que poderão emergir.

Parece natural a emersão de novos portais, não para as pessoas consultarem e usarem, mas para as aplicações, i.e., para os serviços se registrarem/publicarem de modo a tornarem-se conhecidos, descobertos e usados. Esses portais de serviços (tecnicamente consistem em serviços de registros UDDI e/ou ebXML) poderão ser definidos a nível global, regional, para domínios de negócio horizontais ou verticais.

No entanto e naturalmente, novos problemas e requisitos tecnológicos são colocados com o conceito dos Web Services. Desde logo, ao nível da modelação destes serviços e dos processos de negócio em que aqueles participam. Aspectos como a composição de serviços, coordenação de fluxos de trabalho, identificação e privacidade, segurança, negociação, contratos e pagamentos, tratamento de exceções, categorização e taxonomias de serviços, etc., deverão ser adequadamente investigados e tratados de forma que este paradigma possa vir a apresentar um largo consenso e sucesso.

Os Web Services são modelos que surgiram para o desenvolvimento de aplicações típicas de negócio eletrônico, envolvendo e suportando o estabelecimento da colaboração e negociação de forma aberta, distribuída e dinâmica entre distintos parceiros.

Os Web Services podem no futuro representar um sucesso significativo por causa de existir um esforço significativo, por parte da maioria dos parceiros industriais, na normalização das tecnologias envolvidas.

As tecnologias subjacentes aos Web Services (tais como HTTP, SOAP, WSDL, UDDI, XML) são abertas, amplamente divulgadas e consensuais. Por outro lado, existe potencial para haver uma real independência das linguagens de programação (Java, C++, VB, Delphi, C#), das arquiteturas de computadores e sistemas operacionais, o que permite uma evolução mais suave e econômica para este modelo computacional.

No entanto, existem críticas que demonstram medos ou falsas expectativas que os investimentos em Web Services podem suscitar. Uma dessas críticas diz respeito ao fato do SOAP ser menos eficiente do que os sistemas de RPC existentes. Por exemplo, as mensagens (com os respectivos envelopes e descrição de tipos) trocadas entre as partes são descritas em formato de texto/XML enquanto que nos sistemas clássicos de RPC são trocadas em formato binário.

No entanto, esta desvantagem é compensada significativamente pela facilidade de interoperação entre os serviços, sem os problemas conhecidos de segurança/firewalls, e pela facilidade de se esconder os detalhes proprietários das infraestruturas de suporte.

Vantagens

• Integração entre aplicações construídas em diferentes tecnologias;
• Inteligível para o ser humano, o que facilita o desenvolvimento de novos aplicativos utilizando esta tecnologia;
• Intuitiva, pois é descrita em linguagem natural com termos próximos aos utilizadas pela aplicação;
• Precisa, pois a WSDL e o Schema garantem conformidade com os padrões estabelecidos entre provedores e requisitantes.

Desvantagens

• Extremamente verbosa, o que a torna menos produtiva que outras propostas como aqueles que utilizam, por exemplo, JSON.
• Performance de uma aplicação que consome muitos web services é tipicamente inferior;
• Os custos de integração e construção de web services nem sempre são baixos.^[2]

• Web services em Java. Construindo, disponibilizando e acessando Web Services via J2SE e J2ME
• Web Services com NetBeans
• Web Services no devedge.mozilla.org
• Services.NET
• «Portal Nacional da Nota Fiscal Eletrônica» 
• Página referência para Web Service. O w3c é um consórcio internacional que tenta encontrar um padrão para protocolos e linguagens usadas na WEB
• Criando seu web services para sua empresa - Effectlab.com.br
• http://wsxml.wikidot.com/vantagens-e-desvantagens
• https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=security

Referências