Introdução à Computação Móvel

Tecnologia de Web Services aplicada à Computação Móvel

Otavio Rezende da SilvaMatrícula:0115636

1

Índice1. Introdução......................................................................................................................32. Arquitetura Conceitual de Web Services.......................................................................43. Protocolos......................................................................................................................6

3.1 Introdução a XML.............................................................................................73.2 Simple Object Access Protocol (SOAP)...........................................................73.3 Web Services Description Language (WSDL)................................................103.4 Universal Description, Discovery and Integration (UDDI)............................13

4. Ferramentas e Ambientes de Desenvolvimento de Web Services..............................144.1 Microsoft .NET................................................................................................144.2 SunONE...........................................................................................................144.3 HP e-Speak......................................................................................................154.4 IBM Web Services Toolkit..............................................................................154.5 IBM TSSuite....................................................................................................15

5. Estudo de Caso – Serviço de Impressão para Clientes Móveis...................................156. Trabalhos Relacionados...............................................................................................177. Conclusões...................................................................................................................188. Referências..................................................................................................................18

2

1. IntroduçãoAtualmente a web é utilizada principalmente para o acesso interativo a documentos e aplicações. Na maioria dos casos, este acesso é feito através de web browsers, por usuários humanos. No entanto, acredita-se que a partir do momento em que houver uma forte integração entre diferentes aplicações na Internet, o uso da web poderá ser maximizado .

Quando pensamos em computadores móveis, cuja capacidade de processamento, armazenamento e transmissão de dados é limitada, esta necessidade de integração é ainda maior. Por exemplo, tendo acesso a diferentes aplicações distribuídas na web, computadores móveis poderiam solicitar uma série de serviços que executam na rede fixa, recebendo o resultado de seu processamento. Como exemplos podem ser citados serviços de impressão de arquivos, armazenamento de documentos e conversão de formatos.

No entanto, para que uma boa relação custo-benefício seja alcançada. é necessário que esta integração entre aplicações seja efetuada de forma padronizada. Desta forma uma vez desenvolvida a integração de uma aplicação, ela estará pronta para ser acessada por qualquer outra, através de um padrão único. Sendo assim o desenvolvimento específico e artesanal de integração de pares de aplicações é evitado, gerando uma grande economia de gastos no processo de integração como um todo.

É neste contexto que surge a tecnologia denominada Web Services. Esta nova tecnologia permite que aplicações sejam integradas de maneira mais rápida, simples e barata. A chave para alcançar estes resultados está na utilização de um de um modelo comum de comunicação entre programas baseado em padrões existentes e emergentes como HTTP [Fielding 1997], XML [W3C 2000a] (eXtensible Markup Language), SOAP [W3C 2000b](Simple Object Access Protocol), WSDL [W3C 2001] (Web Services Description Language) e UDDI [McKee 2001] (Universal Description, Discovery and Integration).

Um Web Service pode ser definido como uma aplicação de software ou um dispositivo de hardware que pode ser acessado ou utilizado através da web. Cada Web Service implementa uma ou mais interfaces de serviço descritas através de linguagens específicas. Estas interfaces descrevem o conjunto de operações às quais o serviço dá suporte, contendo toda a informação necessária para interação com ele, incluindo o formato das mensagens trocadas, o protocolo de transporte utilizado e sua localização. Esta interface esconde os detalhes de implementação do serviço, permitindo sua utilização independentemente da plataforma de hardware ou software na qual ele é implementado ou da linguagem na qual ele é escrito.

Além da especificação de interfaces de descrição, a tecnologia de define um padrão simples e específico para a descoberta de serviços específicos na web. Para tanto é utilizado um broker de serviços, que nada mais é que base de registro onde serviços podem ser publicados e em seguida descobertos por clientes. Um cliente é uma aplicação que usa um ou mais serviços. Em geral, um cliente utiliza um broker para descobrir um serviço e recuperar informações específicas a ele e em seguida invoca operações do serviço diretamente ou utilizando um intermediário. A figura 1 ilustra a interação entre o serviço, o cliente e o broker.

Como já mencionado acima, a tecnologia de Web Services é baseada em padrões abertos, “leves” e baseados em XML. Desta forma os processos de descoberta,

3

descrição, invocação e acesso a serviços também estão baseados nestes protocolos não proprietários. No restante deste trabalho a arquitetura utilizada na tecnologia de Web Services será descrita (seção 2), os protocolos utilizados serão apresentados na seção 3, na seção 4 será mostrada uma aplicação baseada para armazenamento e impressão de arquivos utilizados por clientes móveis. Na seção 4 serão apresentados de maneira sucinta ambientes e ferramentas para o desenvolvimento de Web Services. Na seção 6 serão discutidas comparações com trabalhos relacionados e finalmente serão apresentadas, na seção 7, algumas conclusões.

2. Arquitetura Conceitual de Web ServicesA arquitetura padrão da tecnologia de Web Services pode ser descrita em diversas camadas. Para as diferentes operações de publicação, descoberta e invocação de serviços são necessárias diversas camadas que compõem a denominada “Pilha de Web Services” [Kreger 2001], ilustrada na figura 2. As camadas superiores são construídas utilizando funcionalidades disponibilizadas pelas camadas inferiores. As colunas no lado direito da figura ilustram requisitos necessários em cada um dos níveis da pilha, enquanto o texto da esquerda representa as tecnologias e padrões que são utilizados na implementação de em cada uma das camadas.

Para que Web Services possam ser invocados por um cliente remoto, eles devem ser acessíveis através da rede. Desta forma, na base da pilha está a camada de rede,. Na maioria das vezes é interessante que os serviços sejam acessados através da Internet, sendo então necessária a utilização de protocolos amplamente difundidos na grande rede. Devido a sua onipresença o protocolo HTTP é o principal protocolo no nível de rede utilizado na implementação de Web Services. No entanto, outros protocolos também podem ser utilizados como, por exemplo, SMTP ou FTP. Em caso de implementação de Web Services em redes locais, serviços confiáveis de trocas de mensagens como, por exemplo, IBM MQSeries [IBM 2001a] também podem ser utilizados.

A segunda camada é a de troca de mensagens baseadas em XML. O protocolo SOAP [W3C 2000b] é o escolhido para esta camada devido principalmente ao seu mecanismo padronizado de envelope de mensagens centradas em documentos ou chamada remota

4

Figura 1 Componentes da Arquitetura de Web Services

de procedimentos (RPC). Além disso, o protocolo possui uma maneira padronizada de codificação, isto é, de transformação de tipos de dados específicos a diferentes linguagens de programação aos dados necessários para a mensagem. Maiores detalhes sobre o protocolo SOAP serão fornecidos na próxima seção.

A próxima camada da pilha é a de descrição de serviços. Nesta camada o padrão utilizado é o chamado WSDL. Este padrão é necessário para que se possa interoperar Web Services. WSDL define a interface de comunicação com o serviço assim como a dinâmica de interação com este. Na próxima seção, o padrão WSDL será discutido com maiores detalhes.

Uma arquitetura composta por estas três primeiras camadas é o mínimo necessário para possibilitar a utilização de qualquer Web Service. Enquanto estas camadas apresentam as tecnologias de interoperabilidade entre serviços, as duas próximas camadas, de publicação e de descoberta de serviços, podem ser implementadas através de uma gama variada de soluções.

Qualquer ação que torna um documento WSDL disponível para um cliente, em qualquer estágio do ciclo de vida deste, é qualificada como a publicação de um serviço. O exemplo mais simples e estático de implementação desta camada é o envio de um documento WSDL diretamente ao cliente. Esta forma de publicação, chamada de publicação direta, pode simplesmente utilizar o e-mail como veículo de comunicação. O mecanismo de publicação direta é bastante útil para aplicações que são ligadas estaticamente a serviços. De maneira alternativa, o provedor do serviço pode publicar o documento WSDL em um broker que poderá ser acessado posteriormente por clientes. Neste broker, a principal tecnologia utilizada é o UDDI, que pode ser visto como o padrão para registrar, descrever e localizar Web Services utilizando uma base de registro compartilhada entre os diferentes clientes.

5

Figura 2 Pilha de protocolos da arquitetura de Web Services

Uma vez que serviços não podem ser descobertos sem terem sido publicados, a camada de descoberta de serviços depende da camada de publicação. Assim como acontece para a publicação, um grande número de abordagens pode ser utilizado nesta camada. Qualquer mecanismo que permite que o cliente tenha acesso a descrição do Web Service e a torna disponível para a aplicação desejada em tempo de execução, pode ser qualificado como um mecanismo de descoberta de serviços. O exemplo mais simples e estático de descoberta é aquele no qual o cliente recupera o documento WSDL a partir de um arquivo local. No entanto, um Web Service pode ser descoberto em tempo de projeto ou de execução, através da busca em uma base de registro comum ou broker.

A criação e gerência desta base de registro e descoberta, compartilhada entre os diversos clientes, são alguns dos pontos críticos do projeto de Web Services. Isto se deve à necessidade de acesso a esta base por diferentes clientes com capacidades de hardware e software diferentes. Desta forma, o protocolo UDDI vem sendo utilizado como tecnologia para a implementação desta base, principalmente por ser baseado em padrões abertos e ubíquos. O protocolo UDDI será apresentado com maiores detalhes na próxima seção.

A implementação de um Web Service pode ser encarada como a de um componente de software. Desta forma, é natural construir novos serviços compondo serviços pré-existentes. Composições de serviços podem desempenhar diferentes papéis. Dentro de um provedor de serviços, diferentes Web Services podem colaborar de forma a apresentar uma interface única para o público. Da mesma forma, diferentes serviços de diferentes provedores podem colaborar de forma a oferecer serviços mais completos ou implementar tarefas de integração. De forma alternativa um gerenciador de workflow pode ser utilizado chamando cada Web Service que participa de um processo específico. A camada mais alta da pilha, denominada camada de fluxo entre serviços, é a responsável por esta tarefa, descrevendo como comunicações entre serviços, colaboração e fluxo de dados são implementados. A tecnologia emergente para a especificação e implementação desta camada está baseada na linguagem WSFL (Web Services Flow Language) [Leymann 2001]. Neste trabalho esta linguagem não será discutida com maiores detalhes, uma vez que esta é, dentre todas as tecnologias utilizadas na implementação de Web Services, a menos estabelecida e validada.

Para que Web Services possam ser utilizados em aplicações reais e escaláveis alguns requisitos de infra-estrutura devem ser oferecidos por cada uma das camadas da pilha. Dentre estes podemos citar segurança, gerenciamento e qualidade de serviço. As soluções adotadas em cada uma das camadas podem seguir abordagens diferentes, e atualmente não existem padrões específicos que possam ser utilizados para que estes requisitos sejam alcançados. Acredita-se que, com o passar do tempo e conseqüente maturidade da tecnologia de Web Services, venham a surgir novos padrões para a implementação destes requisitos.

3. ProtocolosNa seção anterior foi apresentada a arquitetura conceitual de Web Services, baseada em uma pilha de protocolos já estabelecidos ou emergentes. Nesta seção os principais protocolos das camadas de troca de mensagens baseadas em XML (SOAP), descrição de serviços (WSDL), publicação e descoberta de serviços (UDDI) serão apresentados com maiores detalhes. Será apresentada também uma breve introdução a XML uma vez que os diversos protocolos acima são baseados em XML.

6

3.1 Introdução a XMLA linguagem XML (eXtensible Markup Language) [W3C 2000a] foi desenvolvida pelo W3C (World Wide Web Consortium) como um profile de SGML (Standard General Markup Language) designado principalmente para aplicações Web. A partir dessa linguagem, é possível definir criar extensões para linguagens de marcação, através do uso de novas tags. Dados disponíveis em documentos XML são representados de maneira semelhante à de uma fonte semi-estruturada. A flexibilidade oferecida pela linguagem através da definição de novas tags e aninhamento de elementos e a facilidade na troca de informação entre fontes distintas a credenciam como o novo padrão para estruturação, integração e troca de documentos na Internet.

A diferença fundamental entre um documento HTML e um documento XML é a possibilidade de associação de um DTD (Document Type Definition) ao segundo. Esse DTD define a estrutura do documento e o conteúdo associado a cada elemento específico, permitindo que consultas digam respeito não somente aos dados mas também à estrutura, através de linguagens específicas para consultas sobre fontes de dados semi-estruturadas. Ainda, permite que diversas fontes distintas de informação sejam facilmente integradas. Além disso, enquanto tags HTML servem para descrever a forma na qual os dados são apresentados, tags XML servem para descrever a semântica dos dados. Um exemplo simples de documento XML é ilustrado na figura 3.

Uma característica importante em documentos XML é a utilização de namespaces. XML Namespaces são uma forma simples e direta de qualificar nomes de elementos e atributos usados em documentos XML associando-os através de seus prefixos a espaços de nomes identificados por algum URI (Universal Resource Identifier), URL (Uniform Resource Locator), ou URN (Uniform Resource Number). Não há garantias de que XML Namespaces apontem para um recurso real, na prática isso geralmente não acontece. O uso de URIs se dá simplesmente porque elas são globalmente únicas na Internet. Através de namespaces pode-se então diferenciar nomes iguais utilizados para elementos que possuem semânticas diferentes.

3.2 Simple Object Access Protocol (SOAP)SOAP [W3C 2000b] é um mecanismo simples e “leve” (lightweight), baseado em XML, utilizado para trocar dados de forma estruturada entre aplicações. Uma mensagem SOAP é composta por três partes:

7

<?xml version="1.0" encoding="UTF-8"?><!DOCTYPE location [

<!ELEMENT location (lat, long, district)><!ATTLIST locationsystem CDATA #REQUIRED

><!ELEMENT lat (#PCDATA)><!ELEMENT long (#PCDATA)><!ELEMENT district (#PCDATA)>

]><location system="GPS">

<lat>20,53</lat><long>40,23</long><district>QS-110</district>

</location>

Figura 3 Exemplo de documento XML

Um envelope que define um framework para descrever o conteúdo da mensagem;

Um conjunto de regras de codificação para expressar e converter instâncias de tipos de dados definidos em aplicações;

Uma convenção utilizada para representar chamadas e respostas remotas de procedimentos (RPC).

O requisito básico para que um nó da rede seja capaz de participar como requisitante ou provedor de computação distribuída baseada em mensagens SOAP é a capacidade de construir e analisar uma mensagem SOAP bem como a habilidade de se comunicar através da rede. A integração de aplicações pode se feita usando quatro passos básicos, como ilustrado na figura 4:

1. O cliente cria uma mensagem SOAP, que é a mensagem que invoca uma operação específica do Web Service disponibilizada pelo provedor de serviços. O documento XML no corpo da mensagem pode ser formatado como uma requisição em forma de RPC ou uma mensagem centrada em documentos conforme indicado na descrição dos serviços publicada pelo provedor. Junto com a mensagem, o cliente envia para a infra-estrutura SOAP local o endereço na rede do provedor de serviço que, conseqüentemente, interage com um protocolo de rede para enviar a mensagem para o provedor do serviço.

2. A infra-estrutura de rede entrega a mensagem para o servidor SOAP que executa no provedor de serviços, que por sua vez a encaminha para a aplicação que executa o Web Service responsável por ela. O servidor SOAP é o responsável pela conversão do conteúdo da mensagem XML em objetos ou tipos específicos da linguagem que implementa o serviço. Esta conversão é feita utilizando os esquemas de codificação especificados na mensagem SOAP.

8

Figura 4 Seqüência de passos necessária para a integração SOAP

3. O Web Service processa a mensagem de requisição e formula sua resposta que também é uma mensagem SOAP. A mensagem então é enviada com o endereço do cliente como destinatário para o servidor SOAP que se encarrega de enviá-la através da rede.

4. A mensagem de resposta é então entregue à infra-estrutura SOAP local ao cliente que a redireciona à aplicação que executou a requisição. Neste redirecionamento a mensagem XML é convertida para os tipos e objetos específicos da linguagem que implementa a aplicação cliente, que em seguida pode processar a resposta.

Uma mensagem SOAP é um documento XML que contém obrigatoriamente um elemento envelope (SOAP-ENV:Envelope) , um elemento opcional de cabeçalho (SOAP-ENV:Header) e um elemento obrigatório contendo o corpo da mensagem (SOAP-ENV:Body). O elemento envelope é elemento inicial da mensagem (top element), e é o resposnável pelo encapsulamento do conteúdo da mensagem. Este elemento também possui um atributo que especifica regra global de codificação de tipos de dados utilizada na mensagem, maiores detalhes sobre as formas de codificação serão fornecidos a seguir. O elemento envelope deve estar sempre associado ao namespace http://schemas.xmlsoap.org/soap/evelope. Na figura 5 um exemplo simples de mensagem SOAP é ilustrado, onde é possível verificar a utilização do elemento envelope.

O primeiro elemento pertencente ao envelope SOAP é o cabeçalho da mensagem. O cabeçalho é um elemento opcional, que em geral contém informações relativas ao cliente que enviou a mensagem. Estas informações podem ser relativas a segurança contendo uma chave compartilhada entre o cliente e servidor SOAP utilizada para autenticação. Outro tipo de informação que pode estar contida no cabeçalho é um identificador seqüencial da mensagem em uma transação composta por um conjunto de mensagens, como ilustrado na figura 5.

O elemento que contém o corpo da mensagem, SOAP-ENV:Body, provê um mecanismo simples para a troca de informações necessárias para o destinatário final da mensagem. Dentro deste elemento estão contidas informações relativas à mensagem de requisição ou de resposta. Em geral são utilizados elementos cujo nome é o da operação requisitada, e cujos filhos são os parâmetros da requisição ou os dados de resposta da requisição, conforme ilustrado na figura 5. O corpo da mensagem pode possuir um elemento especial para indicar falhas no processamento da mensagem: SOAP-

9

<SOAP-ENV:Envelopexmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope"SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding"/><SOAP-ENV:Header>

<t:Transactionxmlns:t="http://www.teccomm.les.inf.puc-rio.br/ns/t"SOAP-ENV:mustUnderstand="1">2

</t:Transaction></SOAP-ENV:Header><SOAP-ENV:Body>

<m:GetLocation xmlns:m="http://www.teccomm.les.inf.puc-rio.br/ns/t"><lat>20.45</lat><long>43.13</long>

</m:GetLocation></SOAP-ENV:Body>

</SOAP-ENV:Envelope>

Figura 5 Mensagem SOAP básica

ENV:FAULT. Este elemento possui como subelementos que explicitam o código da falha ocorrida, e detalhes sobre a falha ocorrida. Uma mensagem contendo um exemplo de utilização deste elemento é ilustrada na figura 6. Maiores detalhes sobre a formatação do elemento de falha podem ser encontrados em [W3C 2000b].

Um ponto importante na especificação de mensagens SOAP é a codificação de tipos de dados utilizada. O estilo de codificação SOAP é baseado em um sistema de tipos simples que é uma generalização das características comuns encontradas em sistemas de tipos, linguagens de programação, bancos de dados e dados semi-estruturados. Um tipo pode ser simples ou composto, construído como uma composição de várias partes, cada uma com um tipo. A codificação SOAP define um conjunto de regras para a serialização de um grafo de objetos em mensagens XML. Através das mesmas regras é possível executar, no sentido contrário, a transformação (desserialização) de um documento XML em um grafo de objetos. As regras de codificação SOAP suportam além de tipos simples, tipos polimórficos e compostos através de estruturas (struct) ou arrays.

Na verdade a especificação do protocolo SOAP provê um conjunto de regras de codificação, mas usuários do protocolo podem definir suas próprias regras para serem utilizadas nas suas mensagens como um todo ou em partes delas. A especificação do estilo de codificação é especificada através do atributo encodingStyle presente em diferentes trechos da mensagem. Maiores detalhes sobre o mecanismo de codificação podem ser encontrados na versão 1.1 da especificação do protocolo SOAP [W3C 2000b].

3.3 Web Services Description Language (WSDL)Como já mencionado anteriormente, é através da descrição do Web Service que o provedor de serviços publica as especificações necessárias para o cliente invocar um serviço. A descrição do serviço é a chave para tornar a arquitetura de Web Services fracamente acoplada bem como reduzir a quantidade necessária de conhecimento compartilhado entre o cliente e o provedor de serviços. Por exemplo, o cliente não precisa estar ciente da plataforma de execução ou linguagem de programação em que o provedor de serviços está baseado e vice-versa. A descrição do serviço em conjunto

10

<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"> <SOAP-ENV:Body> <SOAP-ENV:Fault> <faultcode>SOAP-ENV:Server</faultcode> <faultstring>Server Error</faultstring> <detail> <e:myfaultdetails xmlns:e="http://www.teccomm.les.inf.puc-rio.br/e"> <message> My application didn't work </message> <errorcode> 1001 </errorcode> </e:myfaultdetails> </detail> </SOAP-ENV:Fault> </SOAP-ENV:Body></SOAP-ENV:Envelope>

Figura 6 Mensagem SOAP contendo indicação de falha no processamento

com a infra-estrutura SOAP adjacente encapsula de maneira apropriada estes tipos de detalhes tanto do cliente quanto do provedor.

A arquitetura usual de Web Services utiliza o padrão WSDL [W3C 2001] (Web Services Description Language) como base para a descrição de serviços. Um documento WSDL é um documento XML utilizado para descrever Web Services como um conjunto de pontos de serviço (endpoints) que operam baseados em torças de mensagens. As operações e mensagens relativas a um serviço são então descritas de forma abstrata e em seguidas atreladas a protocolos de rede e formatos de mensagens concretos como o objetivo de definir um ponto de serviço. WSDL é uma linguagem extensível e permite a descrição de pontos de serviço e suas mensagens independentemente de que formato de mensagens ou protocolo de rede é utilizado na comunicação.

O uso de WSDL na arquitetura de Web Services é em geral dividido em duas partes. São elas a interface do serviço e a implementação do serviço. Deste modo cada parte pode ser definida de maneira independente e conseqüentemente reutilizada por outras aplicações.

Uma especificação de interface de serviço é uma descrição de serviço reutilizável que pode ser instanciada e implementada por diferentes implementações de serviços. Este tipo de especificação é análogo a definição em uma linguagem de programação de uma interface abstrata que possui diferentes implementações concretas como acontece em Java [Gosling 2000] ou IDL [Siegel 1996]. Os elementos que fazem parte da interface de serviço são:

Tipos (types) que provêem definições de tipos de dados que são utilizadas para descrever as mensagens trocadas.

Mensagens (message) que representam uma definição abstrata dos dados que serão transmitidos. Uma mensagem é composta por diferentes partes lógicas que estão associadas com uma definição contida em um sistema de tipos.

Tipos de portos (portType) que são conjuntos de operações abstratas, cada uma contendo mensagens de entrada e saída.

Ligações (binding) que especificam protocolos concretos além de especificações de formatação de dados para as operações e mensagens definidas em um tipo de porto particular.

A definição de implementação de serviço é um documento WSDL que descreve como uma interface particular é implementada por um determinado provedor de serviços. Os elementos que fazem parte da implementação do serviço são:

Porto (port) que especifica um endereço para uma ligação, definindo então um ponto de serviço único.

Serviço (service) que modela um Web Service agregando um conjunto de portos relacionados entre si.

Na verdade as definições de interface e implementação de serviços podem fazer parte de um mesmo documento WSDL como ilustrado na figura 7.

11

Atualmente estão definidas ligações de especificações WSDL para os protocolos SOAP, HTTP e MIME. A especificação detalhada de como estas ligações são implementadas pode ser encontrada em [W3C 2001].

12

<?xml version="1.0"?><definitions name="StockQuote" targetNamespace="http://www.teccomm.les.inf.puc-rio.br/location.wsdl" xmlns:tns="http://www.teccomm.les.inf.puc-rio.br/locationwsdl" xmlns:xsd1="http://www.teccomm.les.inf.puc-rio.br/location.xsd" xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns="http://schemas.xmlsoap.org/wsdl/"> <types> <schema targetNamespace=" http://www.teccomm.les.inf.puc-rio.br/location.xsd " xmlns="http://www.w3.org/1999/XMLSchema"> <element name="Coordinates"> <complexType> <all> <element name="lat" type="float"/> <element name="long" type="float"/> </all> </complexType> </element> <element name="Position"> <complexType> <all> <element name="district" type="string"/> </all> </complexType> </element> </schema> </types> <message name="GetLocationInput"> <part name="body" element="xsd1:Coordinates"/> </message> <message name="GetLocationOutput"> <part name="body" element="xsd1:Position"/> </message> <portType name="LocationPortType"> <operation name="GetLocation"> <input message="tns:GetLocationInput"/> <output message="tns:GetLocationOutput"/> </operation> </portType> <binding name="LocationSoapBinding" type="tns:LocationPortType"> <soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/> <operation name="GetLocation"> <soap:operation soapAction="http://www.teccomm.les.inf.puc-rio.br/GetLocation"/> <input> <soap:body use="literal" namespace="http://www.teccomm.les.inf.puc-rio.br/location.xsd" encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"/> </input> <output> <soap:body use="literal" namespace="http://www.teccomm.les.inf.puc-rio.br/location.xsd" encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"/> </output> </operation> </binding> <service name="LocationService"> <documentation>Location Service</documentation> <port name="LocationPort" binding="tns:LocationBinding"> <soap:address location="http://www.teccomm.les.inf.puc-rio.br/location"/> </port> </service></definitions>

Figura 7 Exemplo de documento WSDL

3.4 Universal Description, Discovery and Integration (UDDI)A especificação do padrão Universal Description, Discovery and Integration (UDDI) define uma maneira de publicar e descobrir informações relativas a Web Services. A primeira vista o processo de descoberta de Web Services pode parecer simples. Na verdade, uma vez que se sabe qual o provedor de serviços que oferece um conjunto de operações agrupadas em serviços, o que mais é preciso descobrir? No entanto, quando é necessário descobrir quais provedores oferecem os serviços desejados, a capacidade de descobrir as respostas torna-se muito mais complicada.

Com a intenção de resolver este problema, UDDI usa uma abordagem baseada em uma base de registros distribuídos de provedores de serviços e suas descrições de serviços, implementada utilizando um formato XML comum [McKee 2001]. Conceitualmente,a informação que faz parte da base de registro UDDI consiste de três componentes:

Páginas brancas: contêm o endereço, pessoas de contato e outros identificadores relativos a um provedor de serviço;

Páginas amarelas: incluem categorizações industriais baseadas em taxonomias padrão;

Páginas verdes: contêm informações específicas sobre serviços disponibilizados pelo provedor.

Na maioria dos casos programas e desenvolvedores usam a base de registros UDDI para localizar informações sobre serviços. No caso específico de programadores a utilização está focada na preparação de sistemas compatíveis com Web Services anunciados ou para descrever seus próprios serviços que serão utilizados por terceiros.

A especificação do UDDI descreve uma nuvem conceitual de Web Services e uma interface programável que define um framework simples para a descrição de qualquer tipo de serviço. Esta especificação consiste em um esquema XML para a estrutura de dados [Ehnebuske 2001] e um outro que contém uma API [McKee 2001] que define um protocolo para registro e descoberta de serviços.

O esquema XML que representa os dados em um documento UDDI possui quatro tipos de dados principais [Ehnebuske 2001], conforme ilustrado na figura 8:

businessEntity: contém informações relativas à entidade que publica informações sobre uma família de serviços;

13

Figura 8 Informação no esquema XML do UDDI

businessService: contém informações descritivas sobre um serviço particular;

bindingTemplate: contém informações técnicas sobre um serviço e especificações relativa s a sua construção;

tModel: contém descrições a especificações para serviços ou taxonomias. Na verdade, tModels são utilizados como interfaces que são implementadas por bindingTemplates.

Um outro tipo de elemento que também faz parte do esquema UDDI é o publisherAssertion que possui informações relativas a relacionamento entre duas entidades provedoras de serviços. A especificação completa destes elementos pode ser encontrada na UDDI Data Structure Specifiction [Ehnebuske 2001].

Estes tipos de dados fazem parte das requisições e chamadas definidas na UDDI API Schema. Esta API define aproximadamente 25 requisições e 15 respostas formatadas em XML utilizadas na descoberta e publicação de serviços em bases de registro UDDI. Exemplos de requisições podem ser find_service, find_tModel, save_service ou save_business. A especificação completa de todas as mensagens pertencentes à API pode ser encontrada em [McKee 2001].

4. Ferramentas e Ambientes de Desenvolvimento de Web Services

Com a grande promessa de trazer o desenvolvimento de software baseado na Internet para um novo nível, a tecnologia de Web Services atraiu atenção de diversos dos principais integrantes do mercado de software mundial. Nesta seção serão apresentadas de maneira sucinta algumas das iniciativas de grandes empresas desenvolvedoras de software para o desenvolvimento e manutenção de Web Services.

4.1 Microsoft .NETMicrosoft .NET [Platt 2001] é um framework e um conjunto de ferramentas pertencentes ao Visual Studio [Microsoft 2001a] que tem como objetivo principal o desenvolvimento, manutenção e gerência de Web Services. Os diferentes componentes do framework se comunicam utilizando o protocolo SOAP, enquanto o mecanismo de troca de mensagens é implementado através do Microsoft Message Queuing (MSMQ).

Embora este framework e toolkit sejam ricos em funcionalidades, grande parte deles é baseada em tecnologias proprietárias. Em sua primeira versão, .NET não oferece suporte à descrição de serviços através de WSDL nem à utilização de brokers UDDI. Nesta versão Web Services são descritos utilizando SCL (Service Contract Language) e a descoberta é tratada através da utilização do mecanismo baseado em arquivos denominado DISCO [Microsoft 2001b]. Neste mecanismo, interface e implementação de serviços não são separadas, impedindo a busca por serviços que implementem uma interface específica.

4.2 SunONESunONE [Sun 2001] (Sun Microsytems “Open Net Environment”) é um conjunto de produtos que oferece suporte ao desenvolvimento de serviços compatíveis com UDDI, XML, WSDL e SOAP. Um exemplo de produto baseado nesta tecnologia é o ambiente de desenvolvimento Forte que pode ser visto como um concorrente do Microsoft .NET ou do IBM Visual Age [Akerley 1999]. Utilizando suas ferramentas desenvolvedores podem construir de maneira relativamente simples Web Services. No entanto ele não se

14

propõe a resolver os problemas ligados à manutenção, gerência ou implementação em ambiente de produção (deployment) de Web Services.

4.3 HP e-SpeakHewlett Packard’s e-Speak [HP 1999] é um framework e um conjunto de componentes para o desenvolvimento de Web Services. O framework oferece suporte à criação, implementação em ambiente de produção e descoberta de Web Services. Os componentes que fazem parte do e-Speak oferecem suporte de baixo nível a Web Services implementando funcionalidades de segurança e roteamento de mensagens. O framework possibilita a utilização de uma ampla gama de padrões de serviços como, por exemplo, SOAP, XML, UDDI, .NET e o seu próprio J-ESI (Java E-Service Interface). No entanto e-Sepeak não provê um ambiente integrado de desenvolvimento de Web Services.

4.4 IBM Web Services ToolkitO Web Services Toolkit [IBM 2001b] (WSTK) desenvolvido pela IBM provê um conjunto de ferramentas que colaboram no desenvolvimento de Web Services. Ele é compatível com os protocolos SOAP, UDDI e WSDL. Uma das principais funcionalidades do WSTK é a automação da geração de serviços a partir de interfaces descritas em WSDL e vice-versa. O WSTK também permite a busca e publicações de informações relativas a serviços em bases de registro UDDI. Entretanto, WSTK não provê uma infra-estrutura para implementação em ambiente de produção, gerência e monitoramento de Web Services.

4.5 IBM TSSuiteO IBM TSpaces Services Suite [Fontoura 2001] (TSSuite) é uma infra-estrutura para a implementação de Web Services. O TSSuite provê uma API para a criação, implementação em ambiente de produção, invocação e configuração de Web Services. Além da API também é disponibilizado pela infra-estrutura um broker UDDI, além de serviços de notificação e monitoramento de serviços. A infra-estrutura é baseada na tecnologia TSpaces [Wyckoff 1998]. TSpaces pode ser visto como um buffer de comunicação através da rede dotado de funcionalidades de bancos de dados. Ele permite comunicação entre aplicações e dispositivos em uma rede de computadores e sistemas operacionais heterogêneos, utilizando o conceito de espaço compartilhado do modelo de programação Linda [Gelernter 1985]. TSSuite pode ser utilizado em conjunto com o IBM WSTK e Visual Age provendo um ambiente integrado para o desenvolvimento de Web Services. Entretanto por estar baseado na tecnologia de TSpaces a ubiqüidade do protocolo HTTP não é completamente aproveitada o que pode causar problemas na interoperabilidade com outros serviços.

5. Estudo de Caso – Serviço de Impressão para Clientes MóveisCom o objetivo de exemplificar a utilização da tecnologia de Web Services por clientes móveis será apresentado a seguir um serviço de impressão genérico para computadores móveis. O serviço apresentado é baseado na implementação dos serviços Intelligent Print e Print Near Me cuja implementação detalhada é descrita em [Fontoura 2001].

O principal objetivo deste serviço é solucionar problemas relativos a diversidade de clientes (laptops, palmtops, telefones celulares), sistemas operacionais (Linux, Windows, Windows CE, Palm OS), formatos de arquivos (PostScript, PDF, HTML, MS Word) e linguagens de impressão (PCL, PostScript). Além disso, a maioria dos

15

dispositivos móveis do mercado não possui impressora, sendo então necessário executar a impressão de arquivos em dispositivos de impressão ligados a alguma rede fixa. Um dos problemas que o serviço apresentado visa solucionar é a descoberta e acesso a impressoras disponibilizadas na rede fixa.

Em sistemas operacionais Windows os usuários devem instalar drivers específicos para cada uma das impressoras utilizadas. A principal vantagem desta abordagem é que o usuário pode ter acesso a características específicas de cada impressora. Já em sistemas operacionais do tipo Unix, através do protocolo LDP/LPR a instalação de drivers não é necessária na máquina do usuário, mas o acesso a atributos especiais do dispositivo de impressão não é garantido. A utilização da tecnologia de Web Services para serviços de impressão pode aproveitar o lado bom das duas abordagens. Por manter um acoplamento fraco entre o cliente e a impressora não é necessário para o cliente a instalação nenhum tipo de driver e quando novas impressoras são adicionadas à rede de serviços podem ser descobertas pelos clientes.

A figura 9 ilustra o serviço proposto. No passo 1 o usuário através de um computador móvel executa uma busca em um servidor UDDI por um serviço de impressão localizado próximo a ele especificando as características específicas desejadas. O servidor UDDI retorna então as informações necessárias para que o cliente possa se “ligar” (binding) ao serviço. A partir do momento da ligação (2) o cliente pode fazer requisições diretas de impressão ao serviço utilizando troca de mensagens SOAP, sem se preocupar com detalhes específicos de implementação como, por exemplo, drivers de impressoras. A partir da requisição o serviço de impressão pode se conectar de maneira transparente a outros serviços como por exemplo serviços de conversão de tipos de arquivos (passo 3).

Uma outra abordagem possível é a utilização de um serviço de localização em conjunto com o serviço de impressão. Esta abordagem, utilizada no serviço Print Near Me, apesar de mais complexa, pode ser implementada de maneira simples através da composição de serviços, como ilustrado na figura 10. Nesta abordagem o cliente móvel solicita a impressão do arquivo desejado a um serviço global de impressão (passo 1). Este serviço global se conecta a um serviço de localização passando informações relativas ao hub através do qual o computador móvel está conectado à rede sem fio (2). O serviço de localização responde então enviando informações sobre serviço de impressão que contém a impressora mais próxima do cliente. Através destas

16

UDDI

UDDI API1

PrintingService

WSDL

SOAP

2

File Convesrion Service

WSDLSOAP

3

Figura 9 Serviço de impressão

informações o serviço global se conecta ao serviço de impressão e solicita que o arquivo enviado pelo cliente seja impresso (3). Também através de composição de serviços, outros serviços mais sofisticados podem ser criados, por exemplo, a composição do serviço de impressão com serviços que contenham repositórios remotos de arquivos. Desta forma o computador móvel não precisaria conter localmente o arquivo que deseja imprimir.

6. Trabalhos RelacionadosExistem algumas tecnologias anteriores à definição da arquitetura de Web Services que se dispõem a resolver o mesmo conjunto de problemas relacionados à interoperabilidade de serviços distribuídos. Jini [Arnold 1999], desenvolvido pela Sun Microsystems, foi um dos primeiros toolkits para serviços distribuídos. Jini oferece suporte para descoberta de serviços, invocação remota de métodos (RMI), segurança, transações e eventos. Sua utilização simplifica o desenvolvimento e invocação de serviços e aplicações Java distribuídas principalmente em ambientes de redes locais. Uma vez que um serviço Jini é descoberto a infra-estrutura Jini transmite sua interface sob a forma de uma classe Java que posteriormente funciona como um proxy para o serviço. No entanto, o desenvolvimento de Jini se deu antes do surgimento e aceitação dos padrões abertos que fazem parte da arquitetura de Web Services e sendo assim ele não é baseado em nenhum deles. Desta forma interoperabilidade de Jini com outros serviços torna-se bastante reduzida.

No início dos anos 90, antes mesmo do surgimento de Jini, surgiu a tecnologia denominada CORBA [Siegel 1996] (Common Object Request Broker Architecture) definida pelo Object Management Group (OMG). Esta tecnologia definiu uma linguagem para definição de interfaces (IDL) e APIs que possibilitam comunicações do tipo cliente-servidor entre objetos utilizando implementações específicas de Object Request Brokers (ORB) que funcionam como o middleware que estabelece as relações entre os objetos distribuídos. Em sua versão 1.0 não havia nenhum tipo de interoperabilidade definida entre diferentes ORBs produzidos por diferentes fabricantes.

Com o desenvolvimento da especificação 2.0 de CORBA, foi criado o protocolo IIOP (Inter-ORB Protocol) através do qual os ORBs podem interoperar. No entanto esta interoperabilidade não é completa, uma vez que alguns ORBs possuem otimizações específicas que são perdidas no processo de interoperabilidade, assim como serviços de

17

GlobalPrintingService

WSDL

SOAP

1

LocationService

WSDLSOAP

2PrintingService

WSDLSOAP

3

Figura 10 Serviço de impressão combinado com serviços de localização

mais alto nível como controle de transações e segurança . Segurança é também um ponto importante na comparação de CORBA como a tecnologia de Web Services. Uma vez que CORBA é baseada em um protocolo diferente do HTTP, sua compatibilidade com ferramentas de segurança usuais na Internet como, por exemplo, firewalls é mais complicada. Outro ponto relativo à segurança que pode ser questionado é o controle praticamente total que o objeto cliente possui sobre o objeto servidor, o que não acontece através da utilização de SOAP que é baseado exclusivamente em troca de mensagens.

7. ConclusõesA tecnologia de Web Services surgiu há poucos anos e vem se firmando como o padrão da indústria para a interoperabilidade de serviços distribuídos. No entanto, ainda existe pouca pesquisa no meio acadêmico relacionada a esta tecnologia. O principal fator para a forte aceitação de Web Services pela indústria é o fato dele ser baseado em protocolos abertos que utilizam tecnologias amplamente estabelecidas na Internet, como HTTP e XML.

A interoperabilidade de Web Services é realizada em alto nível permitindo que clientes e serviços sejam fracamente acoplados, separando claramente a interface da implementação. A utilização de Web Services em clientes móveis torna-se especialmente interessante uma vez que grande parte dos serviços necessários a eles pode ser localizada na rede fixa. Os clientes podem então fazer buscas dinâmicas por serviços utilizando bases de registro UDDI, conectar-se a eles e em seguida fazer solicitações utilizando o protocolo SOAP. Apesar destas vantagens e de muitas promessas da indústria relativas a Web Services específicos para acesso de computadores móveis, atualmente não existem muitos serviços deste tipo implementados.

8. Referências[Arnold 1999] K. Arnold, B. Osullivan, R. W. Scheifler, J. Waldo, A. Wollrath, and B. O’Sullivan, The Jini Specification, Addison-Wesley Pub. Co., 1999.

[Akerley 1999] J. Akerley, N. Li, and A. Parlavecchia, Programming with Visual Age for Java 2, Prentice Hall, 1999.

[Ehnebuske 2001] D. Ehnebuske, C. Riegen and D. Rogers (editors), “UDDI Version 2.0 Data Structure Specification,” (http://www.uddi.org/pubs/DataStructure-V2.00-Open-20010608.pdf)

[Fielding 1997] Fielding, R., Gettys, J., Mogul, J., Frystyk, H. and T. Berners-Lee, Hypertext Transfer Protocol -- HTTP/1.1 , RFC 2068, January 1997

[Fontoura 2001] M. Fontoura et al., TSpaces Services Suíte: Automating the development and Managing of Web Services, (submetido para publicação)

[Gelernter 1985] D. Gelernter, “Generative Communication in Linda,” ACM Transactions on Programming Languages and Applications (TOPLAS), 7(1), 80-112, 1985.

[Gosling 2000] J. Gosling, B. Joy, G. Steele, G. Bracha, The Java Language Specification, Second Edition, Addison Wesley, June 2000

[HP 1999] Hewlett-Packard Company, “Ten Ways to Think e-Speak,” 1999, (http://www.espeak.net/library/pdfs/ThinkEspeak.pdf).

18

[IBM 2001a] Web Sphere MQ Familiy Web Site, (http://www-4.ibm.com/software/ts/mqseries/)

[IBM 2001b] IBM, “Web Service Toolkit,” (http://alphaworks.ibm.com/tech/webservicestoolkit).

[Kreger 2001] H. Kreger, Web Services Conceptual Architecture, May 2001, (http://www-4.ibm.com/software/solutions/webservices/pdf/WSCA.pdf)

[Leymann 2001] F. Leymann, “Web Service Flow Language (WSFL 1.0),” 2001, (http://www-4.ibm.com/software/solutions/webservices/pdf/WSFL.pdf).

[McKee 2001] B. McKee, D. Ehnebuske, and D. Rogers (editors), “UDDI Version 2.0 API Specification,” (http://www.uddi.org/pubs/ProgrammersAPI-V2.00-Open-20010608.pdf)

[Microsoft 2001a] Microsoft, Visual Studio .NET, (http://msdn.microsoft.com/vstudio/nextgen/default.asp )

[Microsoft 2001b] Microsoft, “Enabling Discovery for a Web Service,” (http://msdn.microsoft.com/library/default.asp?url=/library/enus/cpguidnf/html/cpconenablingdiscoveryforwebservice.asp).

[Platt 2001] D. S. Platt, Introducing Microsoft .NET, Microsoft Press, 2001.

[Siegel 1996] J. Siegel et al., CORBA Fundamentals and Programming, John Wiley & Sons, 1996

[Sun 2001] Sun Microsystems, “Open Net Environment (ONE) Software Architecture,”(http://www.sun.com/sunone/).

[Wyckoff 1998] P. Wyckoff, S. W. McLaughry, T. J. Lehman and D. A. Ford, “TSpaces,” IBM Systems Journal, 37(3), 454-474, 1998.

[W3C 2000a] Extensible Markup Language (XML) 1.0 (Second Edition), W3C Recommendation 6 October 2000, [online] (http://www.w3.org/TR/2000/REC-xml-20001006)

[W3C 2000b] Simple Object Access Protocol (SOAP) 1.1, W3C Note, May 2000 (http://www.w3.org/TR/2000/NOTE-SOAP20000508/)

[W3C 2001] W3C, “Web Services Description Language (WSDL) 1.1,” 2001 (http://www.w3.org/TR/wsdl).

19