Introduo Computao Mvel

Tecnologia de Web Services aplicada Computao Mvel

Otavio Rezende da Silva Matrcula:0115636

ndice
1. Introduo..........................................................................................................................3 2. Arquitetura Conceitual de Web Services...........................................................................4 3. Protocolos...........................................................................................................................6 3.1 Introduo a XML.......................................................................................................6 3.2 Simple Object Access Protocol (SOAP).....................................................................7 3.3 Web Services Description Language (WSDL).........................................................10 3.4 Universal Description, Discovery and Integration (UDDI)......................................13 4. Ferramentas e Ambientes de Desenvolvimento de Web Services..................................14 4.1 Microsoft .NET..........................................................................................................14 4.2 SunONE.....................................................................................................................14 4.3 HP e-Speak.................................................................................................................15 4.4 IBM Web Services Toolkit........................................................................................15 4.5 IBM TSSuite..............................................................................................................15 5. Estudo de Caso Servio de Impresso para Clientes Mveis......................................15 6. Trabalhos Relacionados...................................................................................................17 7. Concluses.......................................................................................................................18 8. Referncias.......................................................................................................................18

1. Introduo
Atualmente a web utilizada principalmente para o acesso interativo a documentos e aplicaes. Na maioria dos casos, este acesso feito atravs de web browsers, por usurios humanos. No entanto, acredita-se que a partir do momento em que houver uma forte integrao entre diferentes aplicaes na Internet, o uso da web poder ser maximizado . Quando pensamos em computadores mveis, cuja capacidade de processamento, armazenamento e transmisso de dados limitada, esta necessidade de integrao ainda maior. Por exemplo, tendo acesso a diferentes aplicaes distribudas na web, computadores mveis poderiam solicitar uma srie de servios que executam na rede fixa, recebendo o resultado de seu processamento. Como exemplos podem ser citados servios de impresso de arquivos, armazenamento de documentos e converso de formatos. No entanto, para que uma boa relao custo-benefcio seja alcanada. necessrio que esta integrao entre aplicaes seja efetuada de forma padronizada. Desta forma uma vez desenvolvida a integrao de uma aplicao, ela estar pronta para ser acessada por qualquer outra, atravs de um padro nico. Sendo assim o desenvolvimento especfico e artesanal de integrao de pares de aplicaes evitado, gerando uma grande economia de gastos no processo de integrao como um todo. neste contexto que surge a tecnologia denominada Web Services. Esta nova tecnologia permite que aplicaes sejam integradas de maneira mais rpida, simples e barata. A chave para alcanar estes resultados est na utilizao de um de um modelo comum de comunicao entre programas baseado em padres 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 aplicao de software ou um dispositivo de hardware que pode ser acessado ou utilizado atravs da web. Cada Web Service implementa uma ou mais interfaces de servio descritas atravs de linguagens especficas. Estas interfaces descrevem o conjunto de operaes s quais o servio d suporte, contendo toda a informao necessria para interao com ele, incluindo o formato das mensagens trocadas, o protocolo de transporte utilizado e sua localizao. Esta interface esconde os detalhes de implementao do servio, permitindo sua utilizao independentemente da plataforma de hardware ou software na qual ele implementado ou da linguagem na qual ele escrito. Alm da especificao de interfaces de descrio, a tecnologia de define um padro simples e especfico para a descoberta de servios especficos na web. Para tanto utilizado um broker de servios, que nada mais que base de registro onde servios podem ser publicados e em seguida descobertos por clientes. Um cliente uma aplicao que usa um ou mais servios. Em geral, um cliente utiliza um broker para descobrir um servio e recuperar informaes especficas a ele e em seguida invoca operaes do servio diretamente ou utilizando um intermedirio. A figura 1 ilustra a interao entre o servio, o cliente e o broker. Como j mencionado acima, a tecnologia de Web Services baseada em padres abertos, leves e baseados em XML. Desta forma os processos de descoberta, descrio, invocao e acesso a servios tambm esto baseados nestes protocolos no proprietrios. No restante deste trabalho a arquitetura utilizada na tecnologia de Web Services ser

descrita (seo 2), os protocolos utilizados sero apresentados na seo 3, na seo 4 ser mostrada uma aplicao baseada para armazenamento e impresso de arquivos utilizados por clientes mveis. Na seo 4 sero apresentados de maneira sucinta ambientes e ferramentas para o desenvolvimento de Web Services. Na seo 6 sero discutidas comparaes com trabalhos relacionados e finalmente sero apresentadas, na seo 7, algumas concluses.

Figura 1 Componentes da Arquitetura de Web Services

2. Arquitetura Conceitual de Web Services

A arquitetura padro da tecnologia de Web Services pode ser descrita em diversas camadas. Para as diferentes operaes de publicao, descoberta e invocao de servios so necessrias diversas camadas que compem a denominada Pilha de Web Services [Kreger 2001], ilustrada na figura 2. As camadas superiores so construdas utilizando funcionalidades disponibilizadas pelas camadas inferiores. As colunas no lado direito da figura ilustram requisitos necessrios em cada um dos nveis da pilha, enquanto o texto da esquerda representa as tecnologias e padres que so utilizados na implementao de em cada uma das camadas. Para que Web Services possam ser invocados por um cliente remoto, eles devem ser acessveis atravs da rede. Desta forma, na base da pilha est a camada de rede,. Na maioria das vezes interessante que os servios sejam acessados atravs da Internet, sendo ento necessria a utilizao de protocolos amplamente difundidos na grande rede. Devido a sua onipresena o protocolo HTTP o principal protocolo no nvel de rede utilizado na implementao de Web Services. No entanto, outros protocolos tambm podem ser utilizados como, por exemplo, SMTP ou FTP. Em caso de implementao de Web Services em redes locais, servios confiveis de trocas de mensagens como, por exemplo, IBM MQSeries [IBM 2001a] tambm 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 de procedimentos (RPC). Alm disso, o protocolo possui uma maneira padronizada de codificao, isto , de transformao de tipos de dados especficos a diferentes linguagens

de programao aos dados necessrios para a mensagem. Maiores detalhes sobre o protocolo SOAP sero fornecidos na prxima seo. A prxima camada da pilha a de descrio de servios. Nesta camada o padro utilizado o chamado WSDL. Este padro necessrio para que se possa interoperar Web Services. WSDL define a interface de comunicao com o servio assim como a dinmica de interao com este. Na prxima seo, o padro WSDL ser discutido com maiores detalhes. Uma arquitetura composta por estas trs primeiras camadas o mnimo necessrio para possibilitar a utilizao de qualquer Web Service. Enquanto estas camadas apresentam as tecnologias de interoperabilidade entre servios, as duas prximas camadas, de publicao e de descoberta de servios, podem ser implementadas atravs de uma gama variada de solues.

Figura 2 Pilha de protocolos da arquitetura de Web Services Qualquer ao que torna um documento WSDL disponvel para um cliente, em qualquer estgio do ciclo de vida deste, qualificada como a publicao de um servio. O exemplo mais simples e esttico de implementao desta camada o envio de um documento WSDL diretamente ao cliente. Esta forma de publicao, chamada de publicao direta, pode simplesmente utilizar o e-mail como veculo de comunicao. O mecanismo de publicao direta bastante til para aplicaes que so ligadas estaticamente a servios. De maneira alternativa, o provedor do servio 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 padro para registrar, descrever e localizar Web Services utilizando uma base de registro compartilhada entre os diferentes clientes. Uma vez que servios no podem ser descobertos sem terem sido publicados, a camada de descoberta de servios depende da camada de publicao. Assim como acontece para a

publicao, um grande nmero de abordagens pode ser utilizado nesta camada. Qualquer mecanismo que permite que o cliente tenha acesso a descrio do Web Service e a torna disponvel para a aplicao desejada em tempo de execuo, pode ser qualificado como um mecanismo de descoberta de servios. O exemplo mais simples e esttico 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 execuo, atravs da busca em uma base de registro comum ou broker. A criao e gerncia desta base de registro e descoberta, compartilhada entre os diversos clientes, so alguns dos pontos crticos 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 implementao desta base, principalmente por ser baseado em padres abertos e ubquos. O protocolo UDDI ser apresentado com maiores detalhes na prxima seo. A implementao de um Web Service pode ser encarada como a de um componente de software. Desta forma, natural construir novos servios compondo servios prexistentes. Composies de servios podem desempenhar diferentes papis. Dentro de um provedor de servios, diferentes Web Services podem colaborar de forma a apresentar uma interface nica para o pblico. Da mesma forma, diferentes servios de diferentes provedores podem colaborar de forma a oferecer servios mais completos ou implementar tarefas de integrao. De forma alternativa um gerenciador de workflow pode ser utilizado chamando cada Web Service que participa de um processo especfico. A camada mais alta da pilha, denominada camada de fluxo entre servios, a responsvel por esta tarefa, descrevendo como comunicaes entre servios, colaborao e fluxo de dados so implementados. A tecnologia emergente para a especificao e implementao desta camada est baseada na linguagem WSFL (Web Services Flow Language) [Leymann 2001]. Neste trabalho esta linguagem no ser discutida com maiores detalhes, uma vez que esta , dentre todas as tecnologias utilizadas na implementao de Web Services, a menos estabelecida e validada. Para que Web Services possam ser utilizados em aplicaes reais e escalveis alguns requisitos de infra-estrutura devem ser oferecidos por cada uma das camadas da pilha. Dentre estes podemos citar segurana, gerenciamento e qualidade de servio. As solues adotadas em cada uma das camadas podem seguir abordagens diferentes, e atualmente no existem padres especficos que possam ser utilizados para que estes requisitos sejam alcanados. Acredita-se que, com o passar do tempo e conseqente maturidade da tecnologia de Web Services, venham a surgir novos padres para a implementao destes requisitos.

3. Protocolos
Na seo anterior foi apresentada a arquitetura conceitual de Web Services, baseada em uma pilha de protocolos j estabelecidos ou emergentes. Nesta seo os principais protocolos das camadas de troca de mensagens baseadas em XML (SOAP), descrio de servios (WSDL), publicao e descoberta de servios (UDDI) sero apresentados com maiores detalhes. Ser apresentada tambm uma breve introduo a XML uma vez que os diversos protocolos acima so baseados em XML. 3.1 Introduo a XML A 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 aplicaes Web. A partir dessa 6

linguagem, possvel definir criar extenses para linguagens de marcao, atravs do uso de novas tags. Dados disponveis em documentos XML so representados de maneira semelhante de uma fonte semi-estruturada. A flexibilidade oferecida pela linguagem atravs da definio de novas tags e aninhamento de elementos e a facilidade na troca de informao entre fontes distintas a credenciam como o novo padro para estruturao, integrao e troca de documentos na Internet.
<?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE location [ <!ELEMENT location (lat, long, district)> <!ATTLIST location system 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

A diferena fundamental entre um documento HTML e um documento XML a possibilidade de associao de um DTD (Document Type Definition) ao segundo. Esse DTD define a estrutura do documento e o contedo associado a cada elemento especfico, permitindo que consultas digam respeito no somente aos dados mas tambm estrutura, atravs de linguagens especficas para consultas sobre fontes de dados semi-estruturadas. Ainda, permite que diversas fontes distintas de informao sejam facilmente integradas. Alm disso, enquanto tags HTML servem para descrever a forma na qual os dados so apresentados, tags XML servem para descrever a semntica dos dados. Um exemplo simples de documento XML ilustrado na figura 3. Uma caracterstica importante em documentos XML a utilizao de namespaces. XML Namespaces so uma forma simples e direta de qualificar nomes de elementos e atributos usados em documentos XML associando-os atravs de seus prefixos a espaos de nomes identificados por algum URI (Universal Resource Identifier), URL (Uniform Resource Locator), ou URN (Uniform Resource Number). No h garantias de que XML Namespaces apontem para um recurso real, na prtica isso geralmente no acontece. O uso de URIs se d simplesmente porque elas so globalmente nicas na Internet. Atravs de namespaces pode-se ento diferenciar nomes iguais utilizados para elementos que possuem semnticas 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 aplicaes. Uma mensagem SOAP composta por trs partes: Um envelope que define um framework para descrever o contedo da mensagem; Um conjunto de regras de codificao para expressar e converter instncias de tipos de dados definidos em aplicaes;

 Uma conveno utilizada para representar chamadas e respostas remotas de procedimentos (RPC).

Figura 4 Seqncia de passos necessria para a integrao SOAP

O requisito bsico para que um n da rede seja capaz de participar como requisitante ou provedor de computao distribuda baseada em mensagens SOAP a capacidade de construir e analisar uma mensagem SOAP bem como a habilidade de se comunicar atravs da rede. A integrao de aplicaes pode se feita usando quatro passos bsicos, como ilustrado na figura 4: 1. O cliente cria uma mensagem SOAP, que a mensagem que invoca uma operao especfica do Web Service disponibilizada pelo provedor de servios. O documento XML no corpo da mensagem pode ser formatado como uma requisio em forma de RPC ou uma mensagem centrada em documentos conforme indicado na descrio dos servios publicada pelo provedor. Junto com a mensagem, o cliente envia para a infra-estrutura SOAP local o endereo na rede do provedor de servio que, conseqentemente, interage com um protocolo de rede para enviar a mensagem para o provedor do servio. 2. A infra-estrutura de rede entrega a mensagem para o servidor SOAP que executa no provedor de servios, que por sua vez a encaminha para a aplicao que executa o Web Service responsvel por ela. O servidor SOAP o responsvel pela converso do contedo da mensagem XML em objetos ou tipos especficos da linguagem que implementa o servio. Esta converso feita utilizando os esquemas de codificao especificados na mensagem SOAP. 3. O Web Service processa a mensagem de requisio e formula sua resposta que tambm uma mensagem SOAP. A mensagem ento enviada com o endereo do cliente como destinatrio para o servidor SOAP que se encarrega de envi-la atravs da rede.

4. A mensagem de resposta ento entregue infra-estrutura SOAP local ao cliente que a redireciona aplicao que executou a requisio. Neste redirecionamento a mensagem XML convertida para os tipos e objetos especficos da linguagem que implementa a aplicao cliente, que em seguida pode processar a resposta.
<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope" SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding"/> <SOAP-ENV:Header> <t:Transaction xmlns: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 bsica

Uma mensagem SOAP um documento XML que contm obrigatoriamente um elemento envelope (SOAP-ENV:Envelope) , um elemento opcional de cabealho (SOAPENV:Header) e um elemento obrigatrio contendo o corpo da mensagem (SOAPENV:Body). O elemento envelope elemento inicial da mensagem (top element), e o resposnvel pelo encapsulamento do contedo da mensagem. Este elemento tambm possui um atributo que especifica regra global de codificao de tipos de dados utilizada na mensagem, maiores detalhes sobre as formas de codificao sero 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 possvel verificar a utilizao do elemento envelope. O primeiro elemento pertencente ao envelope SOAP o cabealho da mensagem. O cabealho um elemento opcional, que em geral contm informaes relativas ao cliente que enviou a mensagem. Estas informaes podem ser relativas a segurana contendo uma chave compartilhada entre o cliente e servidor SOAP utilizada para autenticao. Outro tipo de informao que pode estar contida no cabealho um identificador seqencial da mensagem em uma transao composta por um conjunto de mensagens, como ilustrado na figura 5. O elemento que contm o corpo da mensagem, SOAP-ENV:Body, prov um mecanismo simples para a troca de informaes necessrias para o destinatrio final da mensagem. Dentro deste elemento esto contidas informaes relativas mensagem de requisio ou de resposta. Em geral so utilizados elementos cujo nome o da operao requisitada, e cujos filhos so os parmetros da requisio ou os dados de resposta da requisio, conforme ilustrado na figura 5. O corpo da mensagem pode possuir um elemento especial para indicar falhas no processamento da mensagem: SOAP-ENV:FAULT. Este elemento possui como subelementos que explicitam o cdigo da falha ocorrida, e detalhes sobre a falha ocorrida. Uma mensagem contendo um exemplo de utilizao deste elemento ilustrada na figura 6. Maiores detalhes sobre a formatao do elemento de falha podem ser encontrados em [W3C 2000b].

Um ponto importante na especificao de mensagens SOAP a codificao de tipos de dados utilizada. O estilo de codificao SOAP baseado em um sistema de tipos simples que uma generalizao das caractersticas comuns encontradas em sistemas de tipos, linguagens de programao, bancos de dados e dados semi-estruturados. Um tipo pode ser simples ou composto, construdo como uma composio de vrias partes, cada uma com um tipo. A codificao SOAP define um conjunto de regras para a serializao de um grafo de objetos em mensagens XML. Atravs das mesmas regras possvel executar, no sentido contrrio, a transformao (desserializao) de um documento XML em um grafo de objetos. As regras de codificao SOAP suportam alm de tipos simples, tipos polimrficos e compostos atravs de estruturas (struct) ou arrays. Na verdade a especificao do protocolo SOAP prov um conjunto de regras de codificao, mas usurios do protocolo podem definir suas prprias regras para serem utilizadas nas suas mensagens como um todo ou em partes delas. A especificao do estilo de codificao especificada atravs do atributo encodingStyle presente em diferentes trechos da mensagem. Maiores detalhes sobre o mecanismo de codificao podem ser encontrados na verso 1.1 da especificao do protocolo SOAP [W3C 2000b].
<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 indicao de falha no processamento

3.3 Web Services Description Language (WSDL) Como j mencionado anteriormente, atravs da descrio do Web Service que o provedor de servios publica as especificaes necessrias para o cliente invocar um servio. A descrio do servio a chave para tornar a arquitetura de Web Services fracamente acoplada bem como reduzir a quantidade necessria de conhecimento compartilhado entre o cliente e o provedor de servios. Por exemplo, o cliente no precisa estar ciente da plataforma de execuo ou linguagem de programao em que o provedor de servios est baseado e vice-versa. A descrio do servio em conjunto com a infraestrutura SOAP adjacente encapsula de maneira apropriada estes tipos de detalhes tanto do cliente quanto do provedor. A arquitetura usual de Web Services utiliza o padro WSDL [W3C 2001] (Web Services Description Language) como base para a descrio de servios. Um documento WSDL um documento XML utilizado para descrever Web Services como um conjunto de pontos de servio (endpoints) que operam baseados em toras de mensagens. As operaes e 10

mensagens relativas a um servio so ento 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 servio. WSDL uma linguagem extensvel e permite a descrio de pontos de servio e suas mensagens independentemente de que formato de mensagens ou protocolo de rede utilizado na comunicao. O uso de WSDL na arquitetura de Web Services em geral dividido em duas partes. So elas a interface do servio e a implementao do servio. Deste modo cada parte pode ser definida de maneira independente e conseqentemente reutilizada por outras aplicaes. Uma especificao de interface de servio uma descrio de servio reutilizvel que pode ser instanciada e implementada por diferentes implementaes de servios. Este tipo de especificao anlogo a definio em uma linguagem de programao de uma interface abstrata que possui diferentes implementaes concretas como acontece em Java [Gosling 2000] ou IDL [Siegel 1996]. Os elementos que fazem parte da interface de servio so: Tipos (types) que provem definies de tipos de dados que so utilizadas para descrever as mensagens trocadas. Mensagens (message ) que representam uma definio abstrata dos dados que sero transmitidos. Uma mensagem composta por diferentes partes lgicas que esto associadas com uma definio contida em um sistema de tipos. Tipos de portos (portType) que so conjuntos de operaes abstratas, cada uma contendo mensagens de entrada e sada. Ligaes (binding) que especificam protocolos concretos alm de especificaes de formatao de dados para as operaes e mensagens definidas em um tipo de porto particular. A definio de implementao de servio um documento WSDL que descreve como uma interface particular implementada por um determinado provedor de servios. Os elementos que fazem parte da implementao do servio so: Porto (port) que especifica um endereo para uma ligao, definindo ento um ponto de servio nico. Servio (service) que modela um Web Service agregando um conjunto de portos relacionados entre si. Na verdade as definies de interface e implementao de servios podem fazer parte de um mesmo documento WSDL como ilustrado na figura 7.

11

<?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

Atualmente esto definidas ligaes de especificaes WSDL para os protocolos SOAP, HTTP e MIME. A especificao detalhada de como estas ligaes so implementadas pode ser encontrada em [W3C 2001].

12

3.4 Universal Description, Discovery and Integration (UDDI) A especificao do padro Universal Description, Discovery and Integration (UDDI) define uma maneira de publicar e descobrir informaes 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 servios que oferece um conjunto de operaes agrupadas em servios, o que mais preciso descobrir? No entanto, quando necessrio descobrir quais provedores oferecem os servios desejados, a capacidade de descobrir as respostas torna-se muito mais complicada. Com a inteno de resolver este problema, UDDI usa uma abordagem baseada em uma base de registros distribudos de provedores de servios e suas descries de servios, implementada utilizando um formato XML comum [McKee 2001]. Conceitualmente,a informao que faz parte da base de registro UDDI consiste de trs componentes: Pginas brancas: contm o endereo, pessoas de contato e outros identificadores relativos a um provedor de servio; Pginas amarelas: incluem categorizaes industriais baseadas em taxonomias padro; Pginas verdes: contm informaes especficas sobre servios disponibilizados pelo provedor.

Na maioria dos casos programas e desenvolvedores usam a base de registros UDDI para localizar informaes sobre servios. No caso especfico de programadores a utilizao est focada na preparao de sistemas compatveis com Web Services anunciados ou para descrever seus prprios servios que sero utilizados por terceiros. A especificao do UDDI descreve uma nuvem conceitual de Web Services e uma interface programvel que define um framework simples para a descrio de qualquer tipo de servio. Esta especificao consiste em um esquema XML para a estrutura de dados [Ehnebuske 2001] e um outro que contm uma API [McKee 2001] que define um protocolo para registro e descoberta de servios.

Figura 8 Informao no esquema XML do UDDI

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: contm informaes relativas entidade que publica informaes sobre uma famlia de servios; 13

 businessService: contm informaes descritivas sobre um servio particular; bindingTemplate: contm informaes tcnicas sobre um servio e especificaes relativa s a sua construo; tModel: contm descries a especificaes para servios ou taxonomias. Na verdade, tModels so utilizados como interfaces que so implementadas por bindingTemplates. Um outro tipo de elemento que tambm faz parte do esquema UDDI o publisherAssertion que possui informaes relativas a relacionamento entre duas entidades provedoras de servios. A especificao completa destes elementos pode ser encontrada na UDDI Data Structure Specifiction [Ehnebuske 2001]. Estes tipos de dados fazem parte das requisies e chamadas definidas na UDDI API Schema. Esta API define aproximadamente 25 requisies e 15 respostas formatadas em XML utilizadas na descoberta e publicao de servios em bases de registro UDDI. Exemplos de requisies podem ser find_service, find_tModel, save_service ou save_business. A especificao 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 nvel, a tecnologia de Web Services atraiu ateno de diversos dos principais integrantes do mercado de software mundial. Nesta seo sero apresentadas de maneira sucinta algumas das iniciativas de grandes empresas desenvolvedoras de software para o desenvolvimento e manuteno de Web Services. 4.1 Microsoft .NET Microsoft .NET [Platt 2001] um framework e um conjunto de ferramentas pertencentes ao Visual Studio [Microsoft 2001a] que tem como objetivo principal o desenvolvimento, manuteno e gerncia de Web Services. Os diferentes componentes do framework se comunicam utilizando o protocolo SOAP, enquanto o mecanismo de troca de mensagens implementado atravs do Microsoft Message Queuing (MSMQ). Embora este framework e toolkit sejam ricos em funcionalidades, grande parte deles baseada em tecnologias proprietrias. Em sua primeira verso, .NET no oferece suporte descrio de servios atravs de WSDL nem utilizao de brokers UDDI. Nesta verso Web Services so descritos utilizando SCL (Service Contract Language) e a descoberta tratada atravs da utilizao do mecanismo baseado em arquivos denominado DISCO [Microsoft 2001b]. Neste mecanismo, interface e implementao de servios no so separadas, impedindo a busca por servios que implementem uma interface especfica. 4.2 SunONE SunONE [Sun 2001] (Sun Microsytems Open Net Environment) um conjunto de produtos que oferece suporte ao desenvolvimento de servios compatveis 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 no se prope a

14

resolver os problemas ligados manuteno, gerncia ou implementao em ambiente de produo (deployment) de Web Services. 4.3 HP e-Speak Hewlett Packards e-Speak [HP 1999] um framework e um conjunto de componentes para o desenvolvimento de Web Services. O framework oferece suporte criao, implementao em ambiente de produo e descoberta de Web Services. Os componentes que fazem parte do e-Speak oferecem suporte de baixo nvel a Web Services implementando funcionalidades de segurana e roteamento de mensagens. O framework possibilita a utilizao de uma ampla gama de padres de servios como, por exemplo, SOAP, XML, UDDI, .NET e o seu prprio J-ESI (Java E-Service Interface). No entanto e-Sepeak no prov um ambiente integrado de desenvolvimento de Web Services. 4.4 IBM Web Services Toolkit O Web Services Toolkit [IBM 2001b] (WSTK) desenvolvido pela IBM prov um conjunto de ferramentas que colaboram no desenvolvimento de Web Services. Ele compatvel com os protocolos SOAP, UDDI e WSDL. Uma das principais funcionalidades do WSTK a automao da gerao de servios a partir de interfaces descritas em WSDL e vice-versa. O WSTK tambm permite a busca e publicaes de informaes relativas a servios em bases de registro UDDI. Entretanto, WSTK no prov uma infra-estrutura para implementao em ambiente de produo, gerncia e monitoramento de Web Services. 4.5 IBM TSSuite O IBM TSpaces Services Suite [Fontoura 2001] (TSSuite) uma infra-estrutura para a implementao de Web Services. O TSSuite prov uma API para a criao, implementao em ambiente de produo, invocao e configurao de Web Services. Alm da API tambm disponibilizado pela infra-estrutura um broker UDDI, alm de servios de notificao e monitoramento de servios. A infra-estrutura baseada na tecnologia TSpaces [Wyckoff 1998]. TSpaces pode ser visto como um buffer de comunicao atravs da rede dotado de funcionalidades de bancos de dados. Ele permite comunicao entre aplicaes e dispositivos em uma rede de computadores e sistemas operacionais heterogneos, utilizando o conceito de espao compartilhado do modelo de programao 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 ubiqidade do protocolo HTTP no completamente aproveitada o que pode causar problemas na interoperabilidade com outros servios.

5. Estudo de Caso Servio de Impresso para Clientes Mveis

Com o objetivo de exemplificar a utilizao da tecnologia de Web Services por clientes mveis ser apresentado a seguir um servio de impresso genrico para computadores mveis. O servio apresentado baseado na implementao dos servios Intelligent Print e Print Near Me cuja implementao detalhada descrita em [Fontoura 2001].

15

1
UDDI API

UDDI 2
S O A P

WSDL
Printing Service

3
SOAP

WSDL
File Convesrion Service

Figura 9 Servio de impresso

O principal objetivo deste servio 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 impresso (PCL, PostScript). Alm disso, a maioria dos dispositivos mveis do mercado no possui impressora, sendo ento necessrio executar a impresso de arquivos em dispositivos de impresso ligados a alguma rede fixa. Um dos problemas que o servio apresentado visa solucionar a descoberta e acesso a impressoras disponibilizadas na rede fixa. Em sistemas operacionais Windows os usurios devem instalar drivers especficos para cada uma das impressoras utilizadas. A principal vantagem desta abordagem que o usurio pode ter acesso a caractersticas especficas de cada impressora. J em sistemas operacionais do tipo Unix, atravs do protocolo LDP/LPR a instalao de drivers no necessria na mquina do usurio, mas o acesso a atributos especiais do dispositivo de impresso no garantido. A utilizao da tecnologia de Web Services para servios de impresso pode aproveitar o lado bom das duas abordagens. Por manter um acoplamento fraco entre o cliente e a impressora no necessrio para o cliente a instalao nenhum tipo de driver e quando novas impressoras so adicionadas rede de servios podem ser descobertas pelos clientes. A figura 9 ilustra o servio proposto. No passo 1 o usurio atravs de um computador mvel executa uma busca em um servidor UDDI por um servio de impresso localizado prximo a ele especificando as caractersticas especficas desejadas. O servidor UDDI retorna ento as informaes necessrias para que o cliente possa se ligar (binding) ao servio. A partir do momento da ligao (2) o cliente pode fazer requisies diretas de impresso ao servio utilizando troca de mensagens SOAP, sem se preocupar com detalhes especficos de implementao como, por exemplo, drivers de impressoras. A partir da requisio o servio de impresso pode se conectar de maneira transparente a outros servios como por exemplo servios de converso de tipos de arquivos (passo 3). Uma outra abordagem possvel a utilizao de um servio de localizao em conjunto com o servio de impresso. Esta abordagem, utilizada no servio Print Near Me, apesar de mais complexa, pode ser implementada de maneira simples atravs da composio de servios, como ilustrado na figura 10. Nesta abordagem o cliente mvel solicita a impresso do arquivo desejado a um servio global de impresso (passo 1). Este servio global se conecta a um servio de localizao passando informaes relativas ao hub

16

atravs do qual o computador mvel est conectado rede sem fio (2). O servio de localizao responde ento enviando informaes sobre servio de impresso que contm a impressora mais prxima do cliente. Atravs destas informaes o servio global se conecta ao servio de impresso e solicita que o arquivo enviado pelo cliente seja impresso (3). Tambm atravs de composio de servios, outros servios mais sofisticados podem ser criados, por exemplo, a composio do servio de impresso com servios que contenham repositrios remotos de arquivos. Desta forma o computador mvel no precisaria conter localmente o arquivo que deseja imprimir.

S O A P
WSDL

WSDL
Printing Service

3
SOAP

2
SOAP

WSDL
Location Service

GlobalPrinting Service

Figura 10 Servio de impresso combinado com servios de localizao

6. Trabalhos Relacionados
Existem algumas tecnologias anteriores definio da arquitetura de Web Services que se dispem a resolver o mesmo conjunto de problemas relacionados interoperabilidade de servios distribudos. Jini [Arnold 1999], desenvolvido pela Sun Microsystems, foi um dos primeiros toolkits para servios distribudos. Jini oferece suporte para descoberta de servios, invocao remota de mtodos (RMI), segurana, transaes e eventos. Sua utilizao simplifica o desenvolvimento e invocao de servios e aplicaes Java distribudas principalmente em ambientes de redes locais. Uma vez que um servio Jini descoberto a infra-estrutura Jini transmite sua interface sob a forma de uma classe Java que posteriormente funciona como um proxy para o servio. No entanto, o desenvolvimento de Jini se deu antes do surgimento e aceitao dos padres abertos que fazem parte da arquitetura de Web Services e sendo assim ele no baseado em nenhum deles. Desta forma interoperabilidade de Jini com outros servios torna-se bastante reduzida. No incio 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 definio de interfaces (IDL) e APIs que possibilitam comunicaes do tipo clienteservidor entre objetos utilizando implementaes especficas de Object Request Brokers (ORB) que funcionam como o middleware que estabelece as relaes entre os objetos distribudos. Em sua verso 1.0 no havia nenhum tipo de interoperabilidade definida entre diferentes ORBs produzidos por diferentes fabricantes. Com o desenvolvimento da especificao 2.0 de CORBA, foi criado o protocolo IIOP (Inter-ORB Protocol) atravs do qual os ORBs podem interoperar. No entanto esta

17

interoperabilidade no completa, uma vez que alguns ORBs possuem otimizaes especficas que so perdidas no processo de interoperabilidade, assim como servios de mais alto nvel como controle de transaes e segurana . Segurana tambm um ponto importante na comparao de CORBA como a tecnologia de Web Services. Uma vez que CORBA baseada em um protocolo diferente do HTTP, sua compatibilidade com ferramentas de segurana usuais na Internet como, por exemplo, firewalls mais complicada. Outro ponto relativo segurana que pode ser questionado o controle praticamente total que o objeto cliente possui sobre o objeto servidor, o que no acontece atravs da utilizao de SOAP que baseado exclusivamente em troca de mensagens.

7. Concluses
A tecnologia de Web Services surgiu h poucos anos e vem se firmando como o padro da indstria para a interoperabilidade de servios distribudos. No entanto, ainda existe pouca pesquisa no meio acadmico relacionada a esta tecnologia. O principal fator para a forte aceitao de Web Services pela indstria 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 nvel permitindo que clientes e servios sejam fracamente acoplados, separando claramente a interface da implementao. A utilizao de Web Services em clientes mveis torna-se especialmente interessante uma vez que grande parte dos servios necessrios a eles pode ser localizada na rede fixa. Os clientes podem ento fazer buscas dinmicas por servios utilizando bases de registro UDDI, conectar-se a eles e em seguida fazer solicitaes utilizando o protocolo SOAP. Apesar destas vantagens e de muitas promessas da indstria relativas a Web Services especficos para acesso de computadores mveis, atualmente no existem muitos servios deste tipo implementados.

8. Referncias
[Arnold 1999] K. Arnold, B. Osullivan, R. W. Scheifler, J. Waldo, A. Wollrath, and B. OSullivan, 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-Open20010608.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 Sute: Automating the development and Managing of Web Services, (submetido para publicao) [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, Specification, Second Edition, Addison Wesley, June 2000 The Java Language

[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 4.ibm.com/software/ts/mqseries/)

MQ

Familiy

Web

Site,

(http://www-

[IBM 2001b] IBM, Web Service Toolkit, (http://alphaworks.ibm.com/tech/webservicestoolkit). [Kreger 2001] H. Kreger, Web Services Conceptual Architecture, May 2001, (http://www4.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-Open20010608.pdf) [Microsoft 2001a] Microsoft, Visual Studio .NET, (http://msdn.microsoft.com/vstudio/nextgen/default.asp ) [Microsoft 2001b] Microsoft, Enabling Discovery for a Web (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 Architecture,(http://www.sun.com/sunone/). Net Environment (ONE) Software Service,

[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-xml20001006) [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