UNIVERSIDADE TIRADENTES CENTRO DE CINCIAS FORMAIS E TECNOLOGIA CCFT CURSO DE TECNOLOGIA EM PROCESSAMENTO DE DADOS

INTEROPERABILIDADE ENTRE SERVIOS UTILIZANDO SOAP

Orientador: Methanias Colao Rodrigues Jnior Co-orientador: Marco Antnio Simes Wilhelm de Arajo Rodrigues

Projeto Supervisionado em Processamento de Dados

Aracaju(SE)-Brasil 2001

UNIVERSIDADE TIRADENTES CENTRO DE CINCIAS FORMAIS E TECNOLOGIA CCFT CURSO DE TECNOLOGIA EM PROCESSAMENTO DE DADOS

INTEROPERABILIDADE ENTRE SERVIOS UTILIZANDO SOAP

Monografia apresentada ao Centro de Cincias Formais e Tecnologia da Universidade Tiradentes UNIT, como requisito para concluso do curso de graduao e obteno do ttulo de Tecnlogo em Processamento de Dados.

Orientador: Methanias Colao Rodrigues Jnior Co-orientador: Marco Antnio Simes

Wilhelm de Arajo Rodrigues Projeto Supervisionado em Processamento de Dados

Aracaju(SE)-Brasil 2001

DATA ________ / _______ / _______

BANCA

(1 Examinador) _______________________________________________ (2 Examinador) _______________________________________________ (3 Examinador) _______________________________________________

iii

Dedico esta monografia memria do meu pai, minha me, pela fora e confiana nas minhas decises, minha famlia que nunca deixou de acreditar no meu sucesso e minha namorada pelo incentivo e pacincia.
Wilhelm de Arajo Rodrigues

iv

AGRADECIMENTOS

Aos colegas de curso, que se tornaram grandes amigos compartilhando comigo desta caminhada.

Aos professores, que se mostraram bastante sensveis aos problemas da vida acadmica.

Ao meu orientador, prof. Methanias Colao, e ao meu co-orientador, prof. Marco Simes, pela coragem e disposio em participar desta monografia guiando cada passo deste trabalho, me concedendo parte do seu valioso tempo.

A todos que confiaram e torceram por mim.

Muito obrigado.

SUMRIO

LISTA DE FIGURAS................................................................................................... ix LISTAS DE TABELAS .................................................................................................x RESUMO.................................................................................................................... xi INTRODUO ......................................................................................................... 12 1 WEB SERVICES ................................................................................................... 15 1.1 O que so web services. ................................................................................. 15 1.2 Utilizao......................................................................................................... 18 1.3 Perspectivas.................................................................................................... 21 1.4 Estrutura dos web services ............................................................................. 22 1.5 A linguagem XML............................................................................................ 26 1.6 Web Services Description Language (WSDL)................................................. 28 1.7 Universal Discovery and Description Integration (UDDI)................................. 29 1.8 Simple Object Access Protocol ( SOAP )....................................................... 30 1.9 WSFL Web Services Flow Language........................................................... 32 2 PROTOCOLOS UTILIZADOS NA CHAMADA A PROCEDIMENTOS REMOTOS 34 2.1 CORBA. .......................................................................................................... 36 2.1.1 Arquitetura - viso geral ........................................................................... 36 2.1.2 Principais vantagens ................................................................................ 43 2.1.3 Limitaes ................................................................................................ 45 2.1.4 Perspectivas Tecnolgicas ....................................................................... 45 2.2 RMI ................................................................................................................. 48 2.2.1 Arquitetura - viso geral ........................................................................... 48

vi

2.2.1.1 - Definio da Interface Remota ............................................................ 50 2.2.1.2 - Implementao da Classe Remota ..................................................... 51 2.2.1.3 - Chamada de Mtodos Remotos.......................................................... 53 2.2.1.4 - Distributed Garbage Collection............................................................ 56 2.2.1.5 - Camadas do RMI ................................................................................ 57 2.3 Vantagens....................................................................................................... 59 2.4 Limitaes....................................................................................................... 60 2.5 Comparativo.................................................................................................... 60 2.6 Enterprise Java Beans ( EJB ) ....................................................................... 62 3 SOAP ( Simple Object Access Protocol ) .............................................................. 64 3.1 Viso geral do protocolo ................................................................................. 65 3.2 Funcionalidades .............................................................................................. 67 3.3 Estrutura ......................................................................................................... 68 3.4 Principais vantagens e limitaes ................................................................... 74 3.4.1 Tamanho da mensagem........................................................................... 75 3.4.2 Complexidade de empacotamento ........................................................... 76 3.4.3 Facilidade de depurao .......................................................................... 76 3.4.4 Interoperabilidade entre sistemas............................................................. 77 3.4.5 Interoperabilidade com outros protocolos................................................. 78 3.5 Problemas de interoperabilidade..................................................................... 79 3.6 Principais projetos e empresas envolvidas ..................................................... 81 4 Exemplo de aplicao............................................................................................ 84 5 CONCLUSO........................................................................................................ 91 6 REFERNCIAS BIBLIOGRFICAS ...................................................................... 94 7 ANEXOS.............................................................................................................. 100

vii

7.1 ANEXO I - Cdigo Fonte da aplicao.......................................................... 101

viii

LISTAS

LISTA DE FIGURAS

Figura 1: Viso da IBM sobre a pilha de um web service ......................................... 23 Figura 2: Viso geral de um web service .................................................................. 25 Figura3: Um exemplo de WSDL ............................................................................... 31 Figura 4: Um exemplo SOAP ................................................................................... 32 Figura 5: Paradigma Cliente-Servidor....................................................................... 35 Figura 6: Representao grfica do ORB e seus servios ....................................... 39 Figura 7: Interao entre ORBs................................................................................ 40 Figura 8: Interaes entre um servidor e um cliente CORBA ................................... 44 Figura 9: Java IIOP. Princpios da interao entre um applet e objetos remotos .. 47 Figura 10: Interao entre um applet e objetos remotos na arquitetura RMI............ 48 Figura 11: Esquema bsico STUB / SKELETON para comunicao entre objetos.. 49 Figura 12: Funcionamento do stub e do skeleton ..................................................... 52 Figura 13: Interao cliente-servidor-RMIRegistry ................................................... 56 Figura 14: Camadas do RMI .................................................................................... 58 Figura 15: Pacotes SOAP dentro de um request e um response HTTP................... 69 Figura 16: Pacote SOAP contendo cabealho com informaes obrigatrias.......... 72 Figura 17 Objetos CORBA utilizando web services .................................................. 81 Figura 18 Web services utilizando objetos CORBA.................................................. 81 Figura 19: Cenrio de execuo do exemplo de aplicao ..................................... 86 Figura 20: Diagrama de classes do web service. ..................................................... 88
ix

LISTAS DE TABELAS
Tabela 1: Comparativo entre caractersticas das arquiteturas CORBA e RMI ......... 62 Tabela 2: Valores escalares suportados pelo protocolo. .......................................... 73 Tabela 3: Principais implementaes SOAP. ........................................................... 83

RESUMO

As arquiteturas de desenvolvimento de sistemas distribudos tm amadurecido bastante nos ltimos anos. Este fato se deve principalmente pela adeso das grandes corporaes, que perceberam na tecnologia de objetos distribudos o novo paradigma no desenvolvimento de sistemas. Tais arquiteturas se baseiam na sua estrutura, nos servios que oferecem e nos protocolos de comunicao que utilizam. Um fator que favorece a difuso de uma arquitetura de objetos distribudos a sua capacidade de interagir com uma outra arquitetura atravs de protocolos de comunicao apropriados. Um dos grandes desafios da atualidade para as arquiteturas de objetos distribudos permitir a interoperabilidade de sistemas disponveis na Internet, atravs de estruturas de segurana (firewalls), independente da linguagem de programao na qual tenham sido escritos. Web Services tem sido considerada a tecnologia que representa a evoluo das arquiteturas de objetos distribudos e se baseia em um protocolo leve, de especificao no proprietria, baseado em XML (Extended Markup Language), chamado SOAP (Simple Object

Access Protocol). Este protocolo, como os seus antecessores, possui uma srie de
vantagens e limitaes, e tem como principal caracterstica a capacidade de permitir a integrao de sistemas distribudos atravs da Web, formando servios capazes de interagir de forma transparente para fornecer aos usurios funcionalidades especficas.

xi

12

INTRODUO

O advento da internet indubitavelmente tocou de forma marcante a vida de uma parcela significante da populao mundial, influenciando na comunicao, educao, lazer, comrcio e finalmente no desenvolvimento de sistemas de informao, este ltimo de forma particular. Informaes privadas de pessoas e empresas passaram a ficar disponveis para o acesso pblico de forma livre em contedo e padronizada na sua estrutura de exibio. Em poucos anos a festejada possibilidade inicial de acesso rpido a contedos estticos em qualquer parte do mundo evoluiu rapidamente para um grande nmero de sistemas dinmicos capazes de receber e produzir informaes de e para os seus usurios, sendo denominados sistemas para internet ou via web.

Recentemente uma nova revoluo teve lugar na rea de desenvolvimento de sistemas voltados para a internet. O termo web services surgiu a princpio para

13

denominar uma nova arquitetura de sistemas voltados para a internet, com especificao inicialmente proprietria da Microsoft, mas vem crescentemente sendo usado como sinnimo para denominar servios disponveis via internet, capazes de interagir entre si trocando informaes de forma padronizada sem requerer para isso nenhuma interveno humana. Para garantir a perfeita interao, ou

interoperabilidade, entre dois ou mais web services a troca de informaes entre estes deve obedecer a uma srie de padres.

Responsvel por garantir a perfeita comunicao entre os sistemas, os protocolos de comunicao desempenham papel fundamental servindo de sustentao para a arquitetura de desenvolvimento. No caso dos web services o protocolo de comunicao a ser utilizado necessitaria de caractersticas particulares para lhe dar possibilidades de implementao capazes de superar as limitaes de outros protocolos de funo semelhante j existentes. Esse novo protocolo precisaria garantir entre outros recursos leveza, flexibilidade, facilidade de implementao e depurao. Para isso foi criado o SOAP ( Simple Object Access

Protocol ). SOAP o protocolo criado nestes moldes para, mais que outro protocolo
de comunicao, ser uma nova tecnologia na qual se baseia um novo paradigma no desenvolvimento de sistemas distribudos, garantindo a interoperabilidade de servios heterogneos, remotamente distribudos, com todos os requisitos necessrios.

Ao longo deste trabalho sero apresentadas algumas arquiteturas de objetos distribudos, os protocolos de comunicao que utilizam, e finalmente, com destaque especial, ser apresentado o protocolo SOAP, abordando-se tambm de maneira

14

introdutria a arquitetura de desenvolvimento na qual est inserido. Sero ressaltados seus recursos, indicadas algumas das suas principais formas de utilizao e expostas algumas das principais ferramentas de desenvolvimento utilizando SOAP. Sero tambm indicados os principais projetos desenvolvidos por grandes empresas e alguns ambientes de desenvolvimento utilizando softwares comerciais e livres.

15

1 WEB SERVICES

1.1 O que so web services.

Hoje, as duas tecnologias mais populares usadas na Internet so correio eletrnico e www. Nos prximos anos provavelmente veremos uma outra tecnologia da Internet tornar-se muito importante: web services". Alguns autores, como Matt Reynolds, costumam definir web sites como sendo estruturas projetadas basicamente para compartilhar informaes e fornecer a interao entre uma pessoa e uma organizao, e web services como sendo uma evoluo onde a interao humana passa a no ser necessria no processo de obteno das informaes. [REYNOLDS 2001a]. Porm, uma abordagem em um maior nvel de detalhamento nos leva idia principal dos web services, que fornecer aos desenvolvedores de sistemas distribudos uma soluo para o problema da comunicao entre os

16

componentes de uma aplicao distribuda atravs de redes distintas de computadores que possuem no ponto de interconexo, dispositivos de segurana, como firewalls, que permitem apenas o trfego de informaes em formatos e de maneiras previamente determinadas. Fornecer uma estrutura capaz de solucionar este problema no caso especfico da Internet, utilizando padres abertos extremamente conhecidos e de alta aceitao o que torna os web services uma tecnologia com grande possibilidade de expanso.

O ato de buscar na Internet alguns tipos de informao pode ser uma tarefa extremamente cansativa e desestimulante. Estes dois ltimos adjetivos ainda conseguem fazer com que os resultados obtidos nem sempre sejam os melhores. Podemos citar algumas situaes: Obter informaes sobre um produto, como por exemplo quais as companhias que fornecem o tal produto por qual preo e com quais condies de pagamento, ou ainda informaes sobre servios, como por exemplo quais hospitais existem dentro de uma determinada regio geogrfica e que sejam capazes de atender uma urgncia em uma determinada especialidade mdica. Esta tarefa pode ser facilitada pela utilizao de web services, onde podemos fornecer simplesmente o nome do produto ou servio e receber toda a sorte de informaes a respeito do objeto da pesquisa. Ao invs do usurio pesquisar dezenas de sites web procura da informao que precisa, o web service se encarrega dessa tarefa removendo a necessidade de interao humana.

Alm de possibilitar que as informaes fornecidas possam transpor sem dificuldade as barreiras dos firewalls, preciso garantir que cada componente da aplicao que ir receber a informao saiba que tipo de informao est recebendo

17

e como essa informao pode ser lida. Para realizar essa tarefa os web services precisam fornecer alm das informaes, informaes sobre essas informaes. Isso feito atravs do uso de XML (Extended Markup Language) [BRAY 2000], que uma linguagem especfica para a marcao de dados. Assim, encapsulado em um documento XML, alm da informao enviada ou requerida, acompanham a mesma os seus meta-dados, que so as informaes sobre a informao. Alm disso, a prpria definio das funcionalidades disponveis em um web service fica registrada em XML.

Os dados sobre dados, meta-dados, so uma das fundaes-chave que tornam possvel a criao dos web services[REYNOLDS 2001b].

Segundo Joe Johnston, web services so uma maneira para programas em uma mquina usarem os recursos de uma outra mquina, por exemplo, atravs do uso de chamadas a procedimentos remotos (RPC). Embora o RPC binrio esteja em evidncia por dcadas, os web services codificam suas conversaes em XML e falam genericamente atravs do protocolo base da Web, HTTP [RAGGET 1998] (Hyper Text Transfer Protocol). Desta maneira, os web services so bem mais fceis de compreender e eliminar erros do que o RPC tradicional. Como cada linguagem que quer se comunicar com um web service deve falar XML, os clientes escritos em uma linguagem podem fazer requisies aos web services onde os programas do lado servidor tenham sido escritos em uma linguagem diferente [JOHNSTON 2001]. Para prover a funcionalidade de disponibilizar servios capazes de interagir entre si atravs da internet, alm do XML, os web services utilizam outros padres adicionais, para definio e registro dos recursos a serem disponibilizados. So o

18

WSDL(Web Services Description Language) [CHRISTENSEN 2001], SOAP (Simple Object Access Protocol) [GUDGIN 2001], UDDI (Universal Discovery and

Description Integration) [UDDI 2000] e WSFL (Web Services Flow Language) [LEYMANN 2001], e sero abordados a seguir.

1.2 Utilizao.

Segundo Matt Reynolds os web services podem ser usados para criar novas oportunidades de negcio, ou para oferecer alguns servios a um custo-benefcio superior ao de seus concorrentes [REYNOLDS 2001b].

Para ilustrar a utilizao de web services, vamos considerar o cenrio de uma grande empresa distribuidora de medicamentos, que possui um escritrio central para administrao e departamento comercial, e com depsitos nas principais capitais do pas. A empresa em si possui uma grande rede subdividida nas unidades que possui. Cada um dos depsitos da empresa representa uma estrutura autnoma cuja funcionalidade receber os produtos dos grandes laboratrios, armazen-los e providenciar a entrega dos pedidos feitos pelos clientes unidade administrativa central, reportando toda a movimentao mesma.

Quando um cliente deseja adquirir um conjunto de medicamentos, este faz uma busca atravs de servidores UDDI [UDDI 2000], que so responsveis pelo registro de web services, procurando quais empresas so capazes de lhe fornecer os

19

medicamentos que deseja. Uma vez selecionado um web service, atravs da especificao WSDL daquele web service, possvel saber qual a maneira de

interagir com o mesmo a fim de obter a informao que deseja. O cliente informa ento os produtos que deseja adquirir e aguarda as informaes relativas aos mesmos, como por exemplo, preo e condies de pagamento. O cliente ento pode providenciar o seu cadastramento junto empresa para que possa efetuar o seu pedido de compra. Sendo o cliente j previamente cadastrado junto companhia, ele pode simplesmente enviar a sua identificao, os produtos e quantidades que deseja adquirir, recebendo ento a informao de quando receber no seu endereo os itens do pedido efetuado.

Na estrutura interna da empresa o mecanismo funciona de forma anloga. A empresa possui um servidor UDDI onde esto registrados, atravs de WSDL, os

web services internos que possui. Esse servidor acessado para descobrir quais os web services sero utilizados para atender a solicitao do cliente. Por exemplo,
necessrio saber quais depsitos da empresa possui os medicamentos que o cliente solicitou e em quanto tempo capaz de realizar a entrega, total ou parcial, uma vez que a entrega pode ser dividida entre dois depsitos, caso um deles no possua os produtos em quantidades suficientes. Essa entrega ser ainda reportada ao setor administrativo para que sejam efetuados os procedimentos devidos, como por exemplo, o acompanhamento das entregas das unidades, para facilitar a avaliao do desempenho de cada uma delas num determinado perodo.

importante lembrar que, como cada unidade autnoma, ou seja, possui sistemas internos prprios, os web services que existem em cada uma das unidades

20

devem interagir quando necessrio com os sistemas internos de cada unidade. Estes sistemas corporativos internos podem utilizar outras tecnologias de objetos distribudos como, por exemplo, CORBA [OMG 2001] e RMI [RMI 1999]. Existem atualmente importantes pesquisas sendo feitas sobre esse tipo de integrao.

Em se tratando de uma empresa pequena, onde todos os setores esto fisicamente prximos, esta teria apenas o seu sistema interno e este iria interagir com o seu web service responsvel por atender os pedidos dos clientes.

Cenrios mais simples podem ser citados. No ambiente comercial muito comum e uma tendncia definitiva o pagamento de contas atravs de cartes de crdito. Operadoras de cartes de crditos poderiam publicar em servidores UDDI os seus web services, atravs de WSDL, responsveis por validar o nmero e a disponibilidade para compra dos cartes de crdito de seus clientes. Neste caso, um comerciante poderia usar um web service que recebesse um nmero de carto do crdito e o valor da transao, validasse se este carto pertence realmente ao cliente, e se tem permisso e limite para que a transao seja efetuada, retornando ento "sim ou no", ou uma informao equivalente.

Para os desenvolvedores que desejam desenvolver programas capazes de interagir com web services existe a necessidade de buscar o web service atravs de servidores UDDI, obter as funcionalidades do web service desejado atravs da sua especificao WSDL, que servir como interface entre o desenvolvedor e o web

service, e escrever o cdigo na linguagem com a qual estiver mais familiarizado.

21

1.3 Perspectivas.

Alguns autores afirmam que os web services tm potencial para ser uma tecnologia revolucionria, tanto para tradicionais fabricantes de softwares

proprietrios quanto para os desenvolvedores que optam pelo cdigo aberto. Baseiam suas afirmaes chamando a ateno para o incio de algumas recentes mudanas que esto ocorrendo como as plataformas de hardware, onde os PCs tradicionais parecem estar sendo deixados um pouco de lado e as atenes esto se voltando para os dispositivos especializados em uma nica finalidade que podem executar aplicaes mltiplas, como por exemplo, palmtops ou dispositivos do tipo

handheld.

Como caracterstica marcante entre as potencialidades destes

dispositivos est o suporte a conexes de rede presente na esmagadora maioria destes dispositivos. Em funo deste novo cenrio que se forma toma fora a idia que, uma vez que ningum gosta das despesas gerais administrativas para instalar e manter aplicaes localmente hospedadas, alugar o software torna-se

particularmente atraente para os negcios e tambm para os usurios ocasionais de computadores caseiros [JOHNSTON 2001].

Segundo Joe Johnston, um fato importante a considerar quando pensamos sobre as perspectivas dos web services que em um mundo em que grandes empresas compram funcionalidades de software de empresas virtuais de web

services, a marca do fornecedor est se tornando cada vez mais irrelevante

enquanto o grau de funcionalidade e interoperabilidade dos servios toma o papel principal. Os vendedores do sistema operacional, por exemplo, tero uma estadia

22

particularmente difcil neste ambiente, uma vez que nas aplicaes que funcionam naqueles sistemas que os consumidores esto interessados. Se uma aplicao

funcionar igualmente bem em dois sistemas operacionais diferentes, provavelmente os fabricantes de hardware sero atrados cada vez mais s variaes de cdigo aberto do UNIX [JOHNSTON 2001].

Todos estes argumentos so altamente relevantes, porm se observarmos os

web services atravs da sua idia inicial, veremos que no futuro o grande fator que
firmar os web services de forma definitiva no cenrio das tecnologias de sistemas distribudos a possibilidade de integrao com outras tecnologias existentes e j consolidadas comercialmente, como CORBA e RMI. Tais tecnologias tm estado presentes no mercado por anos, representam atualmente considervel frao do parque de sistemas distribudos instalados nas corporaes e no devem ser substitudos em um futuro prximo. Assim sendo, as pesquisas atualmente em andamento que tratam da integrao entre estas tecnologias atravs de wrappers que so estruturas de cdigo capazes de converter requisies feitas atravs de web

services, para chamadas em CORBA ou RMI, ou o oposto - sem dvida tero papel
definitivo no futuro dos web services.

1.4 Estrutura dos web services

Algumas empresas como, por exemplo, a Microsoft e a IBM, tem empregado grandes esforos na consolidao da arquitetura para desenvolvimento dos web

23

services. Segundo Greg Flurry, a figura 1 ilustra a viso da IBM sobre a pilha de um web service [FLURRY 2001]. Esta estrutura se torna difundida devido utilizao de
padres existentes e emergentes para facilitar e promover a interoperabilidade e disponibilidade dos servios.

Figura 1: Viso da IBM sobre a pilha de um web service

Inicialmente possvel afirmar que os web services so a evoluo natural das chamadas a procedimentos remotos. De fato, os web services em si no so uma tecnologia muito mais avanada do que o RPC(Remote Procedure Call) do passado, mas conceitos similares aplicados de novas maneiras.

Segundo Al Saganich [SAGANICH 2001], de um modo geral, os web services so uma tecnologia que poder revolucionar a maneira como os servios business-

to-business e business-to-consumer podem ser fornecidos, pois usam uma

variedade de tecnologias para permitir que duas aplicaes comuniquem-se, sendo que, entretanto, nenhuma destas tecnologias considerada uma inovao. O que faz os web services diferentes de outros mecanismos similares so as tecnologias que fornecem o servio.

24

De fato, as tecnologias utilizadas para o fornecimento dos servios internos que constituem a estrutura dos web services se baseiam em padres extremamente conhecidos e difundidos, sendo que agora sendo usados de maneira diferente.

Os web services tm, em seu ncleo, XML como um mecanismo para comunicao e, finalmente, so baseados em trs tecnologias especficas: um mecanismo para registar um servio, um mecanismo para encontrar um servio, e um mecanismo para que duas partes comuniquem-se [SAGANICH 2001].

Qualquer linguagem que possua uma biblioteca ou ferramenta adequada pode ser utilizada para a produo de web services. Hoje, muitos desenvolvedores tm optado por utilizar as APIs Java 2 Enterprise Edition(J2EE) [SHANNON 2001] e XML para disponibilizar web services na Internet. Estas ferramentas estimulam o desenvolvimento fornecendo mtodos simples para estender, interconectar e publicar aplicaes existentes baseadas em J2EE.

Fundamentalmente os padres utilizados para o desenvolvimento de web

services abrangem inicialmente, mas no unicamente, 3 (trs) funcionalidades

bsicas:

Uma maneira de encontrar e registar um servio. Um mecanismo de transporte para alcanar um servio. Uma maneira de definir quais os parmetros de entrada e de sada para tal servio.

25

A combinao dessas funcionalidades fornece uma nova estrutura para o ambiente da computao distribuda. Porm, o que torna os web services to interessantes e atraentes o fato da sua estrutura permitir que implementaes em linguagens diferentes sendo executadas em servidores de fornecedores distintos podendo interagir sem precisar levar em conta como cada uma das implementaes foi escrita.

Figura 2: Viso geral de um web service

A figura 2 mostra um diagrama que representa a estrutura de um web service.

O primeiro e mais importante componente o fornecedor de servio (service

provider). Os fornecedores de servio hospedam vrios servios, alguns dos quais

so expostos como web services. O segundo componente o repositrio de

26

servios (service repository) responsvel pela publicao da informao que os clientes podem usar para encontrar a informao sobre servios publicados na Web. Finalmente, so necessrios vrios mecanismos para encontrar e alcanar os servios. Mais adiante sero abordados cada um dos padres utilizados pelos web

services. A seqncia de eventos ilustrada na figura 2 representa:

A publicao de um servio por um fornecedor em um repositrio externo para que, uma vez registrado, este servio possa ser utilizado por um cliente.

A busca por um servio em um repositrio com a obteno das informaes sobre o servio desejado, tais como, por exemplo, o formato das chamadas de procedimento e o endereo do fornecedor de servio.

A ligao do cliente ao servio procurado para utilizar as funcionalidades que o mesmo oferece.

Toda esta estrutura importante e faz com que os web services sejam o que so. Entretanto, necessrio olhar mais de perto os mecanismos subjacentes que fornecem a base para os web services e porque so fundamentalmente diferentes das tecnologias atuais utilizadas nos sistemas distribudos. Estes mecanismos so representados pelos padres abordados a seguir. So o XML, WSDL e UDDI.

1.5 A linguagem XML

27

Os web services tm no seu ncleo um conjunto fundamental de funcionalidades baseado em XML. XML uma linguagem extensvel cuja principal finalidade a marcao de dados, e por isso uma tecnologia amplamente utilizada hoje para a padronizao e transmisso de mensagens. Uma necessidade bsica para a comunicao entre dois sistemas que seus dados ou mensagens sejam claramente definidos e delimitados. A transmisso de mensagens e dados entre componentes de sistemas distribudos tem sido uma rea em que existe uma grande dificuldade quando existe a necessidade de interoperabilidade entre sistemas diferentes. Dados precisam ser colocados no canal de comunicao de uma forma tal que ambas as extremidades da transmisso possam compreender e ler a informao. Quando os componentes de um sistema pertencem mesma arquitetura (CORBA , por exemplo ) e esto registrados dentro da mesma estrutura de rede, a transmisso de dados no um problema considervel, uma vez que arquiteturas como CORBA e RMI possuem mecanismos que desempenham bem essa funo. Porm quando aplicaes de arquiteturas diferentes precisam conversar ou mesmo quando aplicaes de mesma arquitetura precisam trocar dados atravs de estruturas de segurana, como firewalls, ou ainda quando aplicaes de uma arquitetura precisam interagir com aplicaes cuja estrutura desconhecida pelo desenvolvedor, fundamental que as informaes trocadas entre as aplicaes estejam padronizadas e em um formato muito conhecido e bem definido.

XML surgiu como uma boa soluo fornecendo uma representao clara de dados, bem como um conjunto de validaes e de regras bem definidas. Como resultado, XML tornou-se um veculo excelente para embalagem de dados de

28

maneira que ambos os lados da transmisso possam facilmente ler e compreender. XML tem seus inconvenientes; para o exemplo, muito eloqente, ou seja, transmitir informaes contidas em um XML provoca uma utilizao da rede muito grande, e essa caracterstica apesar de ser um preo particularmente pequeno a pagar com as atuais redes de alta velocidade, deve ser considerada seriamente a depender do tipo de aplicao que se pretende desenvolver. Se a utilizao da rede um ponto crtico da aplicao, a utilizao de XML na comunicao deve ser avaliada de forma extremamente criteriosa.

1.6 Web Services Description Language (WSDL)

WSDL a linguagem que utiliza XML para servir como um meio para fornecedores de servio disponibilizarem suas interfaces de acesso. Estas interfaces, representadas em XML, contm informaes sobre todas as

funcionalidades do servio bem como os tipos de dados necessrios para a sua utilizao, ou seja, tudo que um cliente precisa para saber como utilizar um servio. A representao dos dados se d obedecendo a um dos objetivos dos web services que a transparncia da implementao. Assim essa forma de representao no est associada a nenhuma linguagem especfica de programao. WSDL foi

definida ento como sendo a linguagem padro para descrever a interface e a localizao de um servio.

Especificamente WSDL fornece um nmero de peas-chave de informao:

29

A definio do formato das mensagens que so passadas entre dois pontos finais usando seus elementos < types > e < message > e definies apropriadas de esquemas ( schema ).

A semntica do servio: como ele deve ser chamado para fazer uma transmisso sncrona de solicitao e resposta, sncrona apenas de resposta ou comunicao assncrona.

O ponto final e o transporte do servio atravs do elemento < service >: isto , quem fornece o servio.

Uma ligao atravs do elemento < binding >, isto , como o servio alcanado.

A figura 3 representa um exemplo de um WSDL.

1.7 Universal Discovery and Description Integration (UDDI)

Atualmente para usar um web service, um cliente deve primeiro encontrar o servio, obter a informao sobre como usar o servio, e entender quem possivelmente disponibiliza o servio. A especificao UDDI define um nmero de servios de busca destinados a permitir aos clientes encontrarem e obterem informaes para acessar um web service [SAGANICH 2001].

30

UDDI atualmente prov trs servios especficos:

Traditional White Pages para procura de um web service pelo nome. Traditional Yellow Pages para procura de um web service pelo tpico. Green Pages para buscas mais genricas baseadas nas caractersticas de
um web service.

Fornecedores de servios de UDDI tipicamente operam um servio conhecido como UDDI Business Registry, ou UBR, que pode ser acessado para publicar e solicitar informaes sobre um dado web service.

1.8 Simple Object Access Protocol ( SOAP )

Uma vez que um web service j foi localizado, atravs de busca em servidores UDDI, e que j se sabe como um web service definido, atravs do seu WSDL, necessrio entender como alcanar realmente o servio e fazer uso de suas funcionalidades. Isso feito atravs do SOAP

SOAP o protocolo de comunicao padro dos web services. A especificao SOAP define como podem ser representados diversos tipos de dados atravs de XML, define tambm o padro de representao de mensagens, chamadas RPC e a ligao com o protocolo HTTP. Atravs do SOAP um cliente pode utilizar as

31

funcionalidades oferecidas por um web service atravs de RPC padro ou troca de mensagens.

Figura3: Um exemplo de WSDL

32

Segundo Al Saganich, de maneira simples SOAP um protocolo para encapsular uma requisio em um XML usando protocolos de comunicao padro tais como o HTTP. O poder do SOAP vem do fato de ser simples, fcil de implementar, e bem suportado na indstria [SAGANICH 2001].

Tipicamente, uma chamada SOAP empacotada no corpo de uma requisio HTTP. O exemplo abaixo baseado na especificao SOAP da W3C, e mostra como um servidor HTTP deve receber uma chamada SOAP para alcanar um

POST /StockQuote HTTP/1.1 Host: www.stockquoteserver.com Content-Type: text/xml; charset="utf-8" Content-Length: nnnn SOAPAction: "http://example.org/2001/06/quotes" <env:Envelope xmlns:env="http://www.w3.org/2001/06/soap-envelope" > <env:Body> <m:GetLastTradePrice env:encodingStyle="http://www.w3.org/2001/06/soap-encoding" xmlns:m="http://example.org/2001/06/quotes"> <symbol>DIS</symbol> </m:GetLastTradePrice> </env:Body> </env:Envelope>

servio conhecido como GetLastTradePrice. Figura 4: Um exemplo SOAP

O SOAP ser abordado de maneira mais detalhada a seguir, no captulo 3.

1.9 WSFL Web Services Flow Language

33

WSFL uma linguagem baseada em XML para descrio de composies de

web services. WSFL considera dois tipos de composies de web services: o

primeiro tipo (modelos de fluxo) especifica o modelo apropriado para uso de uma coleo de web services, de modo que a composio resultante descreve uma maneira para alcanar uma meta de negcios particular; tipicamente, o resultado uma descrio de um processo de negcios. O segundo tipo (modelos globais) especifica o modelo de interao de uma coleo de web services; neste caso,o resultado uma descrio das interaes entre os parceiros globais [LEYMANN 2001]. WSFL define atravs da estrutura de um arquivo XML um padro de utilizao de um conjunto de web services tendo como resultado o procedimento para se conseguir utilizar determinada funcionalidade, ou ainda um padro de interao entre vrios web services.

34

2 PROTOCOLOS UTILIZADOS NA CHAMADA A PROCEDIMENTOS REMOTOS

No

paradigma

cliente-servidor,

um

servidor,

atravs

de

mecanismos

apropriados, anuncia um conjunto de servios que fornecem acesso para alguns recursos, tais como, por exemplo, o acesso uma base de dados. O cdigo da implementao desses servios fica armazenado localmente pelo servidor. o servidor quem executa o servio, tendo ento a capacidade de processamento. Quando um cliente precisa acessar um recurso fornecido pelo servidor, isso ser feito atravs de requisies para os servios registrados e oferecidos pelo servidor. O que o cliente precisa apenas possuir um mecanismo para decidir quais dos servios ele deve utilizar. O servidor possui ento o conhecimento, os recursos e processamento.

A programao com objetos distribudos estende um sistema de programao orientado a objetos para permitir que objetos possam ser distribudos atravs de

35

uma rede heterognea, de modo que estes possam interoperar. Esses objetos podem ser distribudos em computadores diferentes por toda uma rede, existindo fora do espao local de endereo de uma aplicao, e ainda aparecer como se eles estivessem locais para a aplicao. A distribuio de objetos atravs da Internet tem merecido ateno especial

A maioria dos sistemas distribudos tem se baseado no paradigma clienteservidor. Ele suportado por tecnologias como: Chamadas Remotas de Procedimento (RPC), Object Request Brokers (CORBA [OMG 2001]), da OMG, e a Invocao de Mtodos Remotos (RMI [RMI 2001]) da linguagem Java.

Recentemente os desenvolvedores tm utilizado uma nova arquitetura de desenvolvimento de sistemas distribudos, web services, baseados no protocolo SOAP[GUDGIN 2001]. Este novo protocolo ser abordado no captulo 3.

A figura 5 representa o paradigma cliente-servidor.

Figura 5: Paradigma Cliente-Servidor

36

2.1 CORBA.

2.1.1 Arquitetura - viso geral

2.1.1.1 Introduo

CORBA (Common Object Request Broker Architecture) um ambiente para aplicaes distribudas orientadas a objeto. O padro CORBA foi introduzido em 1991 (verso 1.1) pela OMG - Object Management Group (um consrcio de empresas sem fins lucrativos com o objetivo de estabelecer normas e especificaes para gerenciamento de objetos para a indstria).

A especificao CORBA foi criada pelo Object Management Group com o intuito de possibilitar o desenvolvimento de sistemas distribudos que possam se integrar com os demais sistemas legados da empresa. Isso obtido pelo fato do CORBA ser uma arquitetura que no baseada em nenhuma linguagem de programao, diferente de outras tecnologias de objetos distribudos onde deve-se usar uma soluo proprietria de um fabricante [COSTA 1998].

Segundo Tnia Pagnussat, o principal objetivo da arquitetura CORBA garantir para o desenvolvedor a idia de transparncia. Essa idia formada pelas noes de Location Transparency e Programming Language Transparency, ou seja, o programador no necessita saber onde o objeto remoto est localizado e em que linguagem de programao foi escrito para poder acess-lo. As aplicaes clientes

37

que usam um objeto CORBA devem se preocupar apenas em obter uma referncia a um desses objetos para que possam us-lo como se fosse um objeto da sua prpria linguagem [PAGNUSSAT 2001]. Podemos assim considerar como principais caractersticas desta arquitetura a transparncia de linguagem, localizao e plataforma , e a interoperabilidade entre ORBs de diferentes fabricantes

CORBA um padro para objetos desenvolvidos em sistemas distribudos. A arquitetura deste padro possibilita mecanismos pelos quais um objeto pode enviar requerimentos ou receber respostas, para/de outro objeto em sistemas distribudos heterogneos, de uma forma transparente como definido pelo ORB padro do OMG. Utiliza um protocolo chamado o Internet Inter-Orb Protocol (IIOP) para objetos

remotos e, uma vez que CORBA somente uma especificao, esta pode ser utilizada em diversas plataformas de sistema operacional, desde mainframes, passando por estaes UNIX at mquinas com Windows ou dispositivos do

handheld desde que haja uma implementao do ORB para aquela plataforma.

Os servios CORBA so especificaes definidas pela OMG, atravs de interfaces IDL (Interface Definition Language), que definem servios em nvel de sistema que ajudam a gerenciar e manter objetos. Uma vez implementados, estes servios podem ser facilmente acoplados s definies de classes dos objetos distribudos via mecanismos de herana, ou delegao.

2.1.1.2 O Object Request Broker ( ORB )

38

ORB (Object Request Broker) - comercialmente conhecido como CORBA - o "corao" da arquitetura que prov os mecanismos de comunicao entre os objetos. O ORB fornece uma estrutura que permite aos objetos conversarem entre si, independente de aspectos especficos da plataforma e tcnicas usadas para implement-los, ou seja, um cliente pode invocar, transparentemente, um mtodo num objeto servidor, o qual pode estar na mesma mquina ou em qualquer lugar da rede. Aplicaes tpicas cliente/servidor usam designs prprios ou um padro reconhecido para definir o protocolo a ser usado entre os dispositivos. Definies de protocolos dependem da linguagem de implementao, transporte na rede, localizao de objetos e de outros fatores. ORBs simplificam este processo. Com um ORB, o protocolo de rede abstrado, o usurio se preocupa apenas com a interface com os objetos, como se estes "fossem locais". claro que os usurios podem definir o protocolo de comunicao entre seus objetos, durante a especificao de suas interfaces. Seguir os padres da arquitetura CORBA garante portabilidade e interoperabilidade de objetos sobre uma rede de sistemas heterogneos.

A figura 6 representa graficamente o ORB e seus servios:

Para que os objetos de linguagens de programao distintas possam se comunicar, necessrio que cada linguagem tenha seu prprio ORB, assim, os objetos tero um meio comum de comunicao. Quando uma aplicao cliente requisita uma referncia para um objeto remoto responsabilidade do ORB cliente encontrar o objeto remoto no sistema distribudo [SILBERSCHATZ 2000]. Ainda segundo Silberschatz, o ORB cliente tambm responsvel por encaminhar

39

chamadas a mtodos remotos para o servidor apropriado e por receber as respostas do servidor.

Cliente

Objeto Remoto

DII

Stubs

Skeleton ORB

DSI

BOA

Figura 6: Representao grfica do ORB e seus servios

A figura 7 ilustra a comunicao entre ORBs atravs do protocolo IIOP, que ser abordado ainda neste captulo. CORBA, porm, suporta outros protocolos alm do IIOP. Isto permite a integrao com outras arquiteturas de sistemas distribudos.

Os stubs e skeletons serviro para fazer o intercmbio de mensagens entre o cliente e o objeto remoto. Quando uma aplicao faz uma chamada a um mtodo de um objeto remoto, a requisio passada diretamente e de forma transparente ao objeto stub desse objeto que ir transformar a chamada do mtodo e os argumentos em um formato apropriado para que possam ser transmitidos para o espao de endereo do objeto remoto. Antes do objeto remoto receber a chamada, o seu objeto

skeleton se encarrega de receber e recompor a requisio para o formato original,

40

alm de refazer todos os passos no sentido inverso para que o retorno do mtodo chegue ao cliente [TECHMETRIX 2000].

Figura 7: Interao entre ORBs

2.1.1.3 As Interfaces CORBA

CORBA baseado, dentre outros aspectos, na construo e armazenamento de interfaces para os objetos. A interface especifica o conjunto de operaes possveis de serem requisitadas por clientes a um determinado objeto. Estas interfaces so armazenadas em repositrios de interfaces. No repositrio de interface os objetos podem fazer requerimentos para obter informaes sobre determinada interface, ou mesmo criar uma nova interface nele.

41

2.1.3.1 Interface Definition Language (IDL)

A IDL uma linguagem genrica de programao; ela permite a descrio de um servio independente de uma linguagem especfica [SILBERSCHATZ 2000].

Antes de se implementar um objeto remoto, necessrio declarar qual ser a sua interface, ou seja, quais sero os mtodos que podero ser chamados remotamente, seus argumentos e valores de retorno. CORBA usa a IDL ( Interface

Definition Language ) para que um cliente possa saber os mtodos pblicos e

atributos de um servidor. O uso dessa linguagem declarativa permite que clientes e servidores escritos em linguagens diferentes possam cooperar.

Essa linguagem oferece tipos de dados pr-definidos como boolean, char e float que sero usados nos mtodos das interfaces como parmetros e valores de retornos. Alm dos tipos primitivos, possvel tambm passar objetos definidos pelo desenvolvedor como argumento e retorno de mtodos, desde que esses objetos estejam devidamente declarados na IDL para que possam ser reconhecidos tanto no lado do objeto remoto quanto no do cliente. Com a IDL, tambm possvel criar excees e especificar quais sero lanadas em um mtodo para que, quando forem geradas no objeto remoto possam ser tratadas na aplicao que realizou a chamada. Com a interface definida na IDL, os desenvolvedores de aplicaes clientes no precisaro nem mesmo saber em que linguagem o objeto remoto est implementado.

42

Cada ORB oferece um compilador IDL para transformar as definies das

interfaces em estruturas nativas da sua linguagem. Cada interface gera pelo menos
uma classe stub, uma skeleton e algumas outras classes que serviro para acessar o ORB e disponibilizar os servios CORBA como Dynamic Invocation Interface (DII)e

Dynamic Skeleton Interface (DSI). Apesar das classes geradas variarem em funo
do ORB, o mapeamento dos tipos da IDL sero sempre os mesmos para uma mesma linguagem independente do ORB. Ou seja, o int na IDL ser sempre o int do C++ assim como o string da IDL ser o java.lang.String do Java. Alm dos tipos primitivos, outros elementos da IDL variam de acordo com a linguagem como o

module e a interface que em C++ torna-se um arquivo header com a declarao da

classe remota baseada na interface e em Java torna-se um package contendo uma
interface Java. Um exemplo de um arquivo IDL seria algo do tipo:

Interface Automobile { long color(); long price(); };

2.1.1.4 GIOP e IIOP

Para permitir que diferentes implementaes de ORB possam se comunicar, o formato das mensagens deve estar bem definido. O CORBA usa o General Inter-Orb

43

Protocol (GIOP) para definir o formato destas mensagens. No interior de uma

mensagem do GIOP h informaes sobre a operao a ser executada no servidor e os parmetros. Parmetros e valores de retorno so enviados em mensagens do GIOP usando o Protocolo de Representao de Dados Comuns (CDR). Este protocolo define o processo de representao das primitivas do IDL em um formato binrio serializado. Isto possibilita a qualquer aplicao CORBA receber e compreender dados no formato CDR de qualquer outra aplicao CORBA.

O Protocolo Inter-Orb Internet (IIOP) define uma camada de transporte para enviar mensagens do GIOP sobre TCP/IP. IIOP estabelece um mapeamento de mensagens do GIOP para mensagens TCP/IP, e o protocolo de comunicao a ser utilizado quando do envio de mensagens do GIOP via Internet.

A figura 8 mostra as interaes entre um servidor CORBA e um cliente:

2.1.2 Principais vantagens

Uma das grandes vantagens da utilizao da tecnologia CORBA a necessidade crescente de adoo de um padro para integrao de aplicativos, principalmente no ambiente middleware. Criar padro de interoperabilidade entre sistemas, mesmo que desenvolvido por diferentes fabricantes, uma das responsabilidades dos fornecedores.

44

Figura 8: Interaes entre um servidor e um cliente CORBA

O fato da independncia de linguagem possibilita que os sistemas j desenvolvidos pela empresa sejam aproveitados e integrados com novas aplicaes mesmo que esses sistemas sejam implementados em linguagens mais antigas como o COBOL. Alm disso, possibilita que para uma determinada tarefa seja usada a linguagem mais apropriada e que o conhecimento dos desenvolvedores em uma tecnologia seja plenamente usado. Uma importante vantagem oferecida pelo CORBA refere-se ao dinamismo que ser obtido na criao de um sistema distribudo que use uma nova linguagem, uma vez que os desenvolvedores que implementaro a parte cliente no precisaro conhecer a linguagem na qual os objetos que desejam acessar foram implementados [COSTA 1998].

A soluo CORBA proporciona escalabilidade corporativa, uma base instalada e uma abordagem baseada em padres.

45

Como foi mostrado anteriormente, para referenciar um objeto remoto no necessrio saber sua localizao na rede o que ir possibilitar a criao de sistemas mais flexveis onde os objetos remotos podem mudar de host sem alterao no cdigo das aplicaes clientes, ou seja, os desenvolvedores tero a abstrao de que o objeto est simplesmente por toda a rede.

2.1.3 Limitaes

Por se tratar de uma tecnologia que no baseada em linguagem, o uso do CORBA obriga a um mapeamento pela IDL de todo objeto que for passado de uma linguagem para outra. Alm disso, nem todos os recursos de uma determinada linguagem podero ser suportados por outra, fazendo com que esses recursos no sejam utilizados.

A especificao CORBA tambm um pouco criticada por no definir com preciso certos servios como BOA. Porm, com a definio do POA na verso CORBA 2.3 foi possvel solucionar muitos dos problemas de interoperabilidade entre ORBs que existiam. Ainda assim, alguns problemas ainda persistem com relao ao servio de nomes.

2.1.4 Perspectivas Tecnolgicas

46

O escopo de execuo das aplicaes distribudas tem ultrapassado os ambientes locais, cruzando fronteiras administrativas e tecnolgicas, provocando uma procura nas caractersticas de interoperabilidade e portabilidade. Para suprir essas necessidades, CORBA surge como uma padronizao, constituda de especificaes abertas, facilitando a portabilidade e os aspectos de

interoperabilidade.

O CORBA foi criado para aplicaes de propsito geral que desejam obter transparncias de distribuio e na forma de gesto de seus recursos. Esses requisitos em aplicaes de tempo real, ou no so desejveis ou no so necessrios. Pesquisas recentes tm apresentado grandes vantagens, objetivando estender as propriedades de portabilidade, interoperabilidade, flexibilidade e reduo de custos nos sistemas de tempo real. Um dos estudos feitos a abordagem de escalonamento adaptativo para aplicaes distribudas em tempo real.

Uma importante pesquisa a utilizao de CORBA, em conjunto com JAVA. O conjunto JAVA/CORBA, em comparao com aplicaes baseadas em CGI, tem uma srie de vantagens como: separao de interfaces e operaes remotas, aceita estruturao de dados, um objeto remoto pode ser criado para manuseio de operaes remotas e gerenciar vrias chamadas remotas, controle pleno da interface pelo usurio e o desenvolvedor pode criar novos componentes a partir de j existentes, o applet gerencia direto as novas interfaces, uma invocao remota pode ser gerenciada por um applet j sendo executada e o objeto servidor remoto pode carregar os recursos antes do pedido. De maneira anloga, o estudo da

integrao CORBA/SOAP tem se mostrado uma grande perspectiva para o futuro. A

47

integrao entre estas arquiteturas tem como principais objetivos fornecer ao CORBA a flexibilidade da comunicao entre objetos distribudos atravs da internet, que caracterstica do SOAP, e por outro lado, procura fornecer ao SOAP camadas que o CORBA tem e que so bastante consistentes como, por exemplo, a de segurana, bem como os servios do CORBA e as velocidade de comunicao em redes privadas e possibilidade de integrao com outros sistemas, tambm caractersticas do CORBA.

Figura 9: Java IIOP. Princpios da interao entre um applet e objetos remotos

A figura 9 ilustra um applet Java sendo executado na mquina virtual Java de um browser , comunicando-se com objetos remotos atravs do protocolo IIOP. Assim como em RMI a arquitetura de comunicao entre os objetos baseada no princpio de stubs and skeletons. O Stub carregado no cliente contm as regras do

proxy do servidor. Atravs dele feita a chamada a um mtodo remoto e a

localizao do servidor se torna transparente para o desenvolvedor. Uma chamada a um mtodo remoto ter a mesma sintaxe que uma chamada a um mtodo local. O

48

lado servidor possui o parceiro do Stub, chamado Skeleton, que representa o cliente para o servidor.

2.2 RMI

2.2.1 Arquitetura - viso geral

Figura 10: Interao entre um applet e objetos remotos na arquitetura RMI

Presente na especificao do JDK 1.1 da Sun, RMI (Remote Method

Invocation) a alternativa totalmente em Java para a criao de aplicaes com

objetos distribudos. Essa tecnologia se prope a estender o objetivo do Java de Escreva uma vez, execute em qualquer lugar com Escreva uma vez, execute em todo lugar. Nesse modelo, o objeto remoto aquele que possui mtodos que podem ser chamados de uma outra Mquina Virtual Java atravs da rede. Mesmo

49

estando o objeto em um ponto de rede totalmente remoto, as chamadas aos mtodos so feitas como se o objeto fosse local, alm de se poder usar todos os recursos da Orientao a Objeto. Nesse sentido, a criao de classes locais e remotas torna-se bastante semelhante, levando em considerao que no h preocupao com aspectos tcnicos ligados rede, ou seja, no h necessidade de uso direto de sockets ou mensagens. RMI prov um grau de abstrao mais elevado que as tcnicas tradicionais de comunicao entre objetos.

RMI disponibiliza uma estrutura de comunicao permitindo que aplicaes ou

applets Java possam estabelecer um dilogo. A figura 10 representa a interao

entre applets e objetos remotos nesta arquitetura. Por ser totalmente ligado ao Java, RMI pode ser implementado de forma relativamente simples. A arquitetura baseada no princpio de stubs e skeletons (j utilizados na comunicao RPC ), conforme ilustrado na figura 11 [TECHMETRIX 2001], e ser detalhado ainda neste captulo. Estas duas classes podem ser geradas pelo programador atravs de um aplicativo (rmic ), ou geradas automaticamente por um mecanismo prprio da arquitetura.

Figura 11: Esquema bsico STUB / SKELETON para comunicao entre objetos

50

2.2.1.1 - Definio da Interface Remota

Uma interface Java uma estrutura que contm apenas declaraes de constantes e de mtodos que devero ser implementados por uma ou vrias classes. Este conjunto de informaes define um comportamento definido pela interface. Sempre que uma classe especifica que ir implementar uma interface, ela dever conter o cdigo da implementao de todos os mtodos contidos na interface que est implementado.

Para uma interface ser remota basta que ela seja derivada da interface

java.rmi.Remote. Com isso, qualquer mtodo que ela declarar poder ser chamado
remotamente, estes mtodos devem lanar excees relacionadas a problemas que podem ocorrer na chamada do mtodo, como por exemplo, falha na conexo entre cliente e servidor. A exceo bsica a ser lanada do tipo

java.rmi.RemoteException.

Um exemplo de cdigo de uma interface algo do tipo:

public interface Hello extends java.rmi.Remote { String sayHello() throws java.rmi.RemoteException; }

As interfaces Java permitem a definio de um padro comportamental na comunicao entre cliente e servidor, de forma semelhante ao papel da IDL CORBA.

51

2.2.1.2 - Implementao da Classe Remota

A implementao da classe remota deve conter os mtodos que esto declarados na sua interface alm dos seus prprios mtodos, sendo que estes ltimos s podero ser chamados da mesma Mquina Virtual Java da classe. Uma importante caracterstica dos mtodos remotos que os objetos de retorno e os que servem como argumento sero passados por referncia se forem remotos e por cpia caso contrrio, alm disso podem ser de qualquer classe Java desde que esta classe implemente a interface java.io.Serializable. Mesmo assim, pode-se usar todos os tipos primitivos do Java como tambm classes mais freqentemente usadas contidas nos pacotes java.util e java.lang.

O processo de serializao de objetos consiste em gerar uma seqncia de bytes (streams) a partir de uma instncia de uma classe e restaurar a instncia a partir da stream que pode at mesmo ser um arquivo em disco. Quando um objeto cliente faz uma requisio a um objeto remoto e o tipo de retorno do mtodo uma classe no remota, feita uma cpia da instncia dessa classe para a forma de

stream para que essa instncia possa ser transportada via TCP/IP para a Mquina
Virtual do objeto cliente, onde a instncia ser reconstituda resultando em uma referncia local classe. Ou seja, o objeto copiado para o endereo de quem est solicitando para que este possa referenci-lo e chamar um de seus mtodos [COSTA 1998].

52

Caso deva ser retornada uma referncia a uma classe remota, a classe no ser copiada para o cliente, mas sim a sua classe stub ser serializada, transportada, carregada e referenciada. Essa classe stub criada automaticamente a partir da classe remota e funciona como um proxy no lado cliente, ou seja, quando o cliente faz a requisio para um objeto remoto, internamente, a requisio feita a classe stub correspondente que se encarrega de [RMI 1999]:

Receber os dados passados na chamada do mtodo remoto; Fazer a chamada ao objeto remoto passando os dados necessrios sob a forma de stream;

Receber de volta o resultado do mtodo repassando-o para o objeto cliente.

No host do objeto remoto, h a sua classe skeleton que funciona de forma similar a stub recebendo as requisies para pass-las ao objeto remoto. Esse sistema est representado na figura 12:

1- Argum ento paraomtodo Objeto Cliente 6- Retorno domtodo 2- Argumento serializado 5- Retorno serializado

3- Argum ento paraomtodo 4- Retorno dom todo Objeto Rem oto

Stub

Skeleton

Figura 12: Funcionamento do stub e do skeleton

Um exemplo da implementao de uma classe remota seria algo do tipo:

53

public class HelloImpl extends UnicastRemoteObject implements Hello { private String name; public String sayHello() throws RemoteException { return "How do you do"; }...

2.2.1.3 - Chamada de Mtodos Remotos

Antes de ser feita uma chamada remota a um mtodo, necessrio que o cliente possua uma referncia classe que contem o mtodo. Deve-se levar em considerao que na Mquina Virtual do cliente apenas a interface remota est presente, portanto o operador new no pode ser usado uma vez que no se pode instanciar uma interface.

Uma maneira de se obter a referncia a partir da chamada de um mtodo que retorna um objeto da classe remota. Como nem sempre existe essa possibilidade, o RMI disponibiliza uma maneira direta de referenciar uma determinada classe remota que consiste no uso do Registry atravs da classe Naming. O RMIRegistry

responde por requisies de conexo aos servidores RMI, os quais registram a si prprios retornando suas interfaces para o cliente. A classe Naming possui o mtodo

lookup que retorna um objeto do tipo Remote que pode ser convertido para a

54

interface da classe remota desejada. Na chamada desse mtodo basta fornecer a string que identifica o objeto no Registry, sendo que essa string deve ter o seguinte
formato: //host/identificador. Onde [RMI 1999]:

host o nmero IP ou nome da mquina onde o objeto remoto est em execuo;

identificador o nome com o qual o objeto remoto foi registrado no mtodo bind.

O Naming.lookup usa uma stub padro para realizar uma chamada remota ao

Registry que ir devolver a stub do objeto associado ao identificador passado como

parmetro. Ou seja, para uma aplicao obter uma referncia a um objeto remoto basta que se conhea onde ele est e qual o seu identificador. Com a referncia, j possvel usar todos os mtodos declarados na interface do objeto remoto da mesma maneira que so usados os mtodos de objetos locais.

Um exemplo da execuo de uma chamada seria:

... try { Hello server = (Hello) Naming.lookup("//" + getCodeBase().getHost() + "/HelloServer"); message = server.sayHello(); } ...

55

Como a carga do Stub completamente transparente, a comunicao mantida sem qualquer programao especfica. A nica parte que necessita ser desenvolvida o registro do servidor no RMIRegistry assim que este iniciado.

Um exemplo da implementao responsvel por este registro basicamente :

public static void main(String args[]) { // O Security manager obrigatrio System.setSecurityManager(new RMISecurityManager()); try { HelloImpl obj = new HelloImpl("HelloServer"); Naming.rebind("HelloServer", obj); System.out.println("server registered"); } catch (Exception e) { } }

Convm lembrar que o RMIRegistry uma aplicao que executa em memria, e que carregada da mesma maneira que qualquer outro mdulo executvel. A figura 13 mostra a interao entre um servidor, um cliente e o RMIRegistry.

56

Figura 13: Interao cliente-servidor-RMIRegistry

2.2.1.4 - Distributed Garbage Collection

O Garbage Collector um recurso automtico oferecido pela linguagem Java cuja finalidade remover da memria objetos instanciados pela aplicao e que no esto mais sendo referenciados. Isso feito efetuando periodicamente uma varredura da memria. um recurso que retira do programador a preocupao em remover da memria objetos instanciados, que existe em outras linguagens.

No ambiente distribudo, a arquitetura RMI disponibiliza um mecanismo mais complexo chamado Distributed Garbage Collection. Este mecanismo estende a

57

funcionalidade do Garbage Collection padro da linguagem Java adicionando o controle sobre os objetos remotos.

Esse sistema usa o algoritmo de contagem de referncias e uma relao dos objetos com as Mquinas Virtuais de onde se originam as chamadas aos objetos. Na primeira referncia, enviada uma mensagem de referenciado ao servidor do objeto, a partir da o contador incrementado a cada nova referncia e decrementado sempre que o runtime do RMI detectar que uma das referncias finalizada. Quando o contador de um objeto remoto chega a zero, uma mensagem de no-referenciado enviada e o runtime do RMI faz uma referncia fraca a esse objeto para que o Garbage Collector da sua Mquina Virtual possa retir-lo da memria[COSTA 1998].

2.2.1.5 - Camadas do RMI

A arquitetura RMI composta por trs camadas distintas: a do Stub/Skeleton; a de Referncia Remota e a de Transporte. Cada uma delas independente e, por isso, a implementao de uma delas pode ser alterado sem afetar o funcionamento das outras. No topo das trs camadas ficam as aplicaes baseadas em RMI que se comunicam atravs da camada do Stub/Skeleton. A representao desse sistema de camadas est mostrado na figura 14:

A primeira camada formada por objetos stubs e skeletons que so criados automaticamente a partir da classe remota usando o utilitrio rmic do JDK. O objeto

stub funciona do lado do cliente como um substituto do objeto remoto recebendo e

serializando as requisies do cliente para poderem ser transportadas para a Mquina Virtual do objeto remoto onde estar o objeto skeleton correspondente que recebe os dados sob a forma de stream para reconstituir a requisio e os

58

argumentos que sero processados no objeto remoto. Aps o mtodo ter sido finalizado, o resultado (valor de retorno ou exceo) ser passado ao skeleton para que o stub possa receber e retornar ao cliente que fez a requisio.

Cliente

Servidor

Aplicao

Stubs Arquitetura RMI

Skeletons

Referncia Remota

Transporte

Figura 14: Camadas do RMI

A comunicao entre os componentes da primeira camada feita atravs da camada de Referncia Remota. Ela a responsvel por distinguir se o objeto remoto est replicado ou no e se ele precisa ser ativado para aceitar requisies, por isso o seu funcionamento vai depender da implementao do objeto chamado. Aps determinar o tipo de objeto remoto, a camada de Referncia Remota dar inicio transferncia dos dados usando um protocolo prprio do RMI chamado JRMP (Java

Remote Method Protocol) por meio da camada de Transporte, uma vez que essa
camada trata dos detalhes de baixo nvel da comunicao como a inicializao e o gerenciamento das conexes. Essa camada baseada em TCP e sockets padres Java, mas poderia ser substituda por outra que usasse UDP [RMI 1999].

59

Atualmente, RMI evidencia a RRL ( Remote Reference Layer Camada de Referncia Remota ) para interface com as camadas de transporte. Porm, a verso 1.3 do JDK ( Java Development Kit ) j suporta a interoperabilidade entre RMI e CORBA, o que a Sun chamou de RMI-IIOP. Um exemplo deste tipo de interoperabilidade est na figura 8 [TECHMETRIX 2001].

2.3 Vantagens

Apesar de algumas limitaes, que sero citadas a seguir, RMI uma alternativa bastante interessante se forem levadas em considerao as seguintes caractersticas:

O uso de objetos distribudos totalmente integrado a linguagem, uma vez que o desenvolvimento de classes locais e remotas bastante semelhante, o que torna a criao das aplicaes bastante simples;

O RMI usa da portabilidade e dos mecanismos de segurana oferecidos pelo ambiente Java;

A presena do Distributed Garbage Collection completamente transparente; A possibilidade de se passar todo um objeto como parmetro possibilita o desenvolvimento de aplicaes distribudas totalmente orientada a objetos;

Alm dos dados o cdigo tambm pode ser transportado;

60

Como o RMI faz parte do Java Development Kit a partir da verso 1.1.x, toda Mquina Virtual Java compatvel com essa verso est apta a executar aplicaes distribudas.

2.4 Limitaes

Atualmente, o uso do RMI limita-se somente pelo fato de seu uso ser restrito ao ambiente Java, ou seja, no possvel que uma aplicao escrita em uma outra linguagem chame um mtodo de um objeto remoto Java atravs de RMI, o que inviabiliza o aproveitamento de sistemas legados da empresa. Apesar do Java oferecer recursos como o JNI (Java Native Interface) que possibilita a integrao com objetos de outras linguagens, o uso desses meios sempre se torna uma soluo inadequada porque os recursos de uma linguagem nem sempre podero ser passados para outra, ficando restritos pelo nvel de compatibilidade das interfaces.

2.5 Comparativo

Segundo Gopalan Raj, a tabela T1 representa um comparativo entre os principais mecanismos e caractersticas das arquiteturas CORBA e RMI [RAJ 2001]. Este comparativo importante para que se possa perceber as semelhanas entre as arquiteturas, uma vez que tanto CORBA quanto RMI fornecem mecanismos

61

transparentes de chamadas remotas a objetos distribudos. Estes mecanismos so diferentes e se baseiam na estrutura de cada arquitetura, mas no impedem a existncia de tais semelhanas.

CORBA
Suporta herana mltipla em nvel de interface Toda interface herda de CORBA.Object Identifica de maneira individual objetos servidores remotos atravs de referncias(objref), que servem para manipulao de objetos em tempo de execuo. Identifica de forma individual uma interface usando seu nome e identifica de forma individual uma implementao especfica de um objeto servidor pelo mapeamento para o seu nome correspondente no Implementation Repository.

RMI
Suporta herana mltipla em nvel de interface Todo objeto servidor implementa java.rmi.Remote Identifica, de maneira individual, objetos servidores remotos com Object IDs, que servem para manipulao de objetos em tempo de execuo. Identifica de forma individual uma interface usando o seu nome e identifica de forma individual uma implementao especfica de um objeto servidor pelo seu mapeamento para uma URL correspondente no Registry.

A gerao de uma referncia para o objeto A gerao de uma referncia para o objeto servidor remoto feita em conjunto com o servidor remoto feita atravs de chamada ao protocolo pelo Object Adapter. mtodo UnicastRemoteObject.exportObject(this) O construtor implcito executa tarefas comuns O RMIRegistry executa tarefas comuns como como registro de objetos, instanciao dos registro de objetos atraves da classe Naming. O skeletons e outras. mtodo UnicastRemoteObject.exportObject(this) Executa a instanciao dos skeletons e chamado implicitamente pelo construtor do objeto. Utiliza o Internet Inter-ORB Protocol(IIOP) como Utiliza o Java Remote Method Protocol(JRMP) protocolo de chamadas remotas como protocolo de chamadas remotas Quando um objeto cliente precisa ativar um objeto Quando um objeto cliente precisa obter uma servidor, ele se liga ao servio de nomes ( naming referncia para um objeto servidor ele deve fazer ) ou a um servio negociante ( trader ). um lookup() na URL do objeto servidor remoto. O manipulador de objetos que o cliente usa a O manipulador de objetos que o cliente usa a referncia a um objeto (Object Reference) referncia a um objeto (Object Reference) O mapeamento do nome do objeto para a sua O mapeamento do nome do objeto para a sua implementao conduzido pelo repositrio de implementao conduzido pelo RMIRegistry. implementaes (Implementation Repository) A informao dos tipos para os mtodos Qualquer informao de tipos guardada pelo guardada pelo repositrio de interfaces(Interface objeto em si e pode ser consultada usando Repository) Reflexo e introspeco. A responsabilidade de localizar a implementao A responsabilidade de localizar a implementao de um objeto recai sobre o Object Request Broker de um objeto recai sobre a Java Virtual Machine (ORB) (JVM), ou mquina virtual Java. A responsabilidade de ativar a implementao de A responsabilidade de ativar a implementao de um objeto recai sobre o Object Adapter (OA) da um objeto da mquina virtual Java. mesma maneira sobre o Basic Object Adapter (BOA) ou o Portable Object Adapter (POA)

62

O stub do lado cliente chamado proxy ou stub. O stub do lado servidor chamado skeleton. Na passagem de parmetros entre o cliente e o objeto servidor remoto, todos os tipos de interface so passados por referncia. Todos os outros objetos so passados por valor, inclusive tipos de dados de alta complexidade.

O stub do lado cliente chamado proxy ou stub. O stub do lado servidor chamado skeleton. Na passagem de parmetros entre o cliente e o objeto servidor remoto, todos os objetos que implementam interfaces que herdem de java.rmi.Remote so passados por referncia remota. Todos os outros objetos so passados por valor.

No se prope a implementar garbage collection Prope-se a implementar garbage collection distribudo. distribudo dos objetos servidores remotos atravs dos mecanismos contidos na mquina virtual. Tipos complexos que ultrapassem as fronteiras da Qualquer objeto java serializvel pode ser interface devem ser declarados na IDL. passado como parmetro atravs dos processos. Pode ser executado em qualquer plataforma Pode ser executado em qualquer plataforma desde que haja uma implementao de ORB para desde que haja uma implementao da mquina a mesma. virtual Java para a plataforma. Uma vez que uma especificao, vrias Uma vez que se baseia extremamente na linguagens de programao podem ser usadas serializao de objetos Java, o cdigo destes para escrever o cdigo dos objetos desde que a objetos s pode ser escrito em Java. linguagem escolhida possua bibliotecas ORB. O tratamento de excees cuidado pelos Permite o lanamento de excees que so ento objetos de exceo. Quando um serializadas e empacotadas para que possam Objeto distribudo lana um objeto de exceo o trafegar no meio. ORB transparentemente serializa e empacota o mesmo para que possa trafegar no meio.

Tabela 1: Comparativo entre caractersticas das arquiteturas CORBA e RMI

2.6 Enterprise Java Beans ( EJB )

Enterprise Java Beans define uma arquitetura para desenvolvimento de

aplicaes de objetos distribudos baseada em componentes server-side que encapsulam a lgica de negcios de uma aplicao. A lgica de negcios o cdigo que satisfaz o propsito da aplicao. A lgica de negcios implementada em mtodos que podem ser chamados por clientes remotos para que possam ter acesso aos servios fornecidos pela aplicao [SUN 2001]. Estes componentes,

63

chamados de EJBs, so executados em uma ambiente especial, chamado de container, desenvolvido exclusivamente para controlar, em tempo de execuo, os aspectos relacionados aos componentes, alm da tarefa de abrigar, gerenciar acesso, segurana, persistncia, controle de transaes, concorrncia e acesso a recurso reservados. Grande parte desse gerenciamento feita automaticamente, sem a interferncia do programador.

Por serem escritos na linguagem Java os EJBs fazem uso dos recursos da tecnologia J2EE ( Java 2 Enterprise Edition ), como utilizao de RMI para chamada a mtodos remotos e JNDI como padro de acesso no servio de nomes, alm da possibilidade de utilizao do CORBA. Da mesma forma, se utiliza a estrutura

stub/skeleton e mecanismo de serializao, porm tendo como particularidade um

ciclo de vida diferenciado, uma vez que so capazes de representar persistncia de dados.

64

3 SOAP ( Simple Object Access Protocol )

SOAP [BOX 2000] um protocolo de comunicao leve, baseado na linguagem XML e concebido para utilizao na troca de informaes entre sistemas em um ambiente descentralizado, distribudo. Consiste basicamente de trs partes: um envelope que define uma estrutura para descrever o contedo de uma mensagem e como o mesmo pode ser processado, um conjunto de regras de controle para expressar instncias de tipos de dados de aplicaes, e uma conveno para representar chamadas a procedimentos remotos e respostas.

SOAP representa uma nova realidade no sentido em que fornece uma nova base no processo de padronizao dos procedimentos de troca de informaes via Internet, atravs de estruturas de segurana ( firewalls).

65

3.1 Viso geral do protocolo

SOAP um protocolo simples, comercialmente independente, e que no define a semntica da aplicao onde ser utilizado como, por exemplo, o modelo de programao; ao invs disto, define uma estrutura simples para expressar a semntica da aplicao por meio de um mecanismo modular de empacotamento de informaes e codificao dos tipos de dados contidos nos pacotes. Esta caracterstica permite a utilizao do SOAP em uma grande variedade de sistemas, desde aqueles baseados em troca de mensagens at os baseados em RPC, independente da linguagem de programao utilizada.

Sempre importante lembrar que SOAP em si apenas um protocolo e no uma arquitetura completa de objetos distribudos. Por outro lado, arquiteturas completas de objetos distribudos so projetadas em torno dos seus protocolos para maior eficincia. Algumas tecnologias de objetos distribudos se preocupam com os prprios aspectos de segurana, por exemplo, e carregam informaes de segurana dentro seus pacotes de dados. Elas tm mecanismos para eficientemente codificar a informao de segurana para aumentar a velocidade de recepo dos dados.

A principal caracterstica do SOAP o objetivo de manter a simplicidade e extensibilidade. Isto faz com que vrios recursos das arquiteturas atuais de objetos distribudos no estejam includos na especificao do SOAP, e torna o SOAP um

66

protocolo atrativo a um grande nmero de projetos. Por exemplo, alguns destes recursos so:

Garbage collection distribudo. Passagem de objetos por referncia (que requer garbage collectiion distribudo)

Tambm, diferente das arquiteturas contemporneas de objetos distribudos, SOAP usa abertamente tecnologias disponveis que, quando combinadas, especificam um protocolo consistente, que pode ser utilizado para auxiliar, principalmente, sistemas distribudos atravs da Internet. O fato de o SOAP utilizar padres bem definidos e aceitos no mercado, como por exemplo a linguagem XML na sua estrutura, tambm estendido aos protocolos de comunicao. SOAP permite a sua utilizao em combinao com uma variedade de outros protocolos de comunicao, como por exemplo HTTP, SMTP e FTP; entretanto, na maioria das aplicaes, normalmente ele utilizado em combinao com o HTTP .

O SOAP geralmente usa o protocolo HTTP para transportar, encapsulados em arquivos XML, dados serializados de argumentos de mtodos, de sistema para sistema. Estes dados serializados de argumentos so utilizados no lado remoto para executar as chamadas aos procedimentos que o cliente fez quele sistema.

67

3.2 Funcionalidades

SOAP fundamentalmente uma estrutura que consiste de uma combinao de informaes textuais compartilhada via a Internet. A informao textual codificada na forma de arquivo XML, que tem regras especficas para codificao e processamento. A transmisso real dos dados do XML administrada pelo protocolo de transporte, que hoje geralmente HTTP servido por um servidor Web. A combinao do estilo aberto da estrutura da linguagem XML e a penetrao do protocolo HTTP tornam o SOAP um protocolo de elevado grau de interoperabilidade.

Uma vez que se pode utilizar HTTP como protocolo de transporte para o SOAP ento o processamento do SOAP est muito ligado com a Internet, que especifica um modelo de programao stateless. Isto , objetos clientes solicitam servios de uma entidade remota, que responde com a informao pertinente. Depois que a entidade remota responde, toda informao de estado referente quela chamada destruda a menos que sejam utilizadas medidas para persistir esta informao para posterior uso.

Servidores SOAP simples seguem este stateless bsico com request/response. Porm o protocolo em si no impede a implementao de servidores mais complexos, capazes de administrao de estado. Esta facilidade possvel tanto para simples scripts quanto para aplicaes mais complexas utilizando SOAP.

68

Utilizando SOAP para a interoperabilidade de servios a estrutura das mensagens encapsuladas em arquivos XML a informao chave e que deve ser conhecida entre as partes que se comunicam. Isto permite que servios disponveis na Web em servidores de plataformas diferentes e que foram escritos utilizando linguagens de programao diferentes possam interagir sem a que seja necessria a interveno humana.

Pelo fato de utilizar protocolos de comunicao extremamente conhecidos e difundidos, e por isso registrados nas estruturas de segurana dispostas na internet (firewalls), as mensagens SOAP conseguem transpor tais estruturas facilmente, sem que seja necessrio nenhum esforo adicional por parte de desenvolvedores e administradores de redes.

3.3 Estrutura

A estrutura do protocolo SOAP baseada em XML, contendo elementos de definio estrutural e elementos de definio do tipo de contedo. Estes elementos sero identificados de acordo com o exemplo ilustrado na Figura 15.Namespaces XML fornecem um mtodo simples de qualificao de elementos e nomes de atributos utilizados em documentos XML associando-os com namespaces identificados por referncias URI (Uniform Resource Identifiers) [RFC2396]. Um namespace XML uma coleo de nomes, identificados por uma referncia URI que so utilizados em documentos XML como tipos [RFC2396].

69

ANEXO I - Cdigo Fonte do prottipo

Figura 15: Pacotes SOAP dentro de um request e um response HTTP

Uma aplicao SOAP deve incluir o namespace SOAP adequado em todos os elementos e atributos definidos pelo SOAP nas mensagens geradas. Uma aplicao de SOAP deve ser capaz de processar namespaces SOAP nas mensagens que receber, descartar mensagens que tm namespaces incorretos e processar mensagens SOAP sem namespaces SOAP como se tivessem namespaces SOAP corretos.

SOAP define dois namespaces:

envelope

de

SOAP

tem

como

identificador

namespace

"<http://schemas.xmlsoap.org/soap/envelope/>"

70

serializador

SOAP

tem

como

identificador

namespace

"<http://schemas.xmlsoap.org/soap/encoding/>"

Os prefixos de namespace "SOAP-ENV" e " SOAP-ENC" esto associados com os namespaces SOAP "<http://schemas.xmlsoap.org/soap/envelope/>" respectivamente. O prefixo e de

"<http://schemas.xmlsoap.org/soap/encoding/>"

namespace "xsi" est associado com o URI "<http://www.w3.org/1999/XMLSchemainstance>" e, analogamente, o prefixo do namespace "xsd" est associado ao URI "<http://www.w3.org/1999/XMLSchema>".. O prefixo de namespace "tns" utilizado para indicar qual o namespace de alvo do documento corrente. O indicador xmlns indica a presena de uma referncia a um namespace ( xmlns = XML namespace). Os outros namespaces encontrados na Figura 15 so meramente exemplos.

Uma mensagem SOAP um documento do XML que consiste de um envelope de SOAP obrigatrio, um cabealho opcional, e um corpo obrigatrio. O namespace que identifica estes atributos da mensagem

"<http://schemas.xmlsoap.org/soap/envelope/>". Os componentes da mensagem SOAP podem ser assim definidos:

O Envelope o elemento principal do documento XML representando a mensagem. serializao O atributo encodingStyle, do Envelope indica o mecanismo de a ser utilizado e est definido no URI

http://schemas.xmlsoap.org/soap/encoding/".

71

O Cabealho um mecanismo genrico para adicionar recursos a uma mensagem de SOAP, de maneira descentralizada, sem acordo prvio entre as partes que esto se comunicando. SOAP define alguns atributos que podem ser utilizados para indicar se as partes devem lidar com um recurso e se este opcional ou obrigatrio. As regras de definio do cabealho so as seguintes:

o Uma entrada no cabealho identificada pela sua referncia completa, que consiste do URI do seu namespace e o seu nome local. Todos os elementos contidos no cabealho devem possuir um namespace vlido especificado. o O atributo encodingStyle pode ser utilizado para identificar o tipo de serializao das entradas do cabealho. o O atributo mustUnderstand e actor podem ser usados para indicar como a entrada do cabealho deve ser processada e por quem, conforme pode ser verificado na Figura 16. O pacote SOAP ilustrado na figura contm a informao sobre uma transao cujo valor 5. A presena do atributo mustUnderstand faz com que esta informao deve ser compreendida pelo receptor da mensagem sob pena da obrigatoriedade de se indicar uma exceo caso isso no acontea. O atributo global actor pode ser utilizado para indicar num elemento do cabealho o receptor final da mensagem. Uma vez que uma mensagem SOAP pode ser repassada por vrias aplicaes at chegar no destino onde ser processada, o valor do atributo actor um URI especial, "<http://schemas.xmlsoap.org/soap/actor/next>", que indica se o elemento de cabealho se destina primeira aplicao SOAP que processar a mensagem. Omitir o atributo actor indica que o receptor o destino final da mensagem SOAP.

O Corpo um recipiente para informao obrigatria destinada ao receptor final da mensagem. SOAP define no corpo um elemento de exceo para que

72

possa ser expressa a ocorrncia de erros. Os elementos de erro SOAP se dividem nos seguintes subelementos: faultcode, indicando o cdigo do erro ocorrido; faultstring, indicando uma explicao textual do erro ocorrido;

faultactor, indicando quem causou o erro durante o caminho percorrido pela

mensagem; detail, cuja presena indica que o contedo do Corpo ( Body ) no foi corretamente processado, s devendo estar presente neste caso particular. Outros elementos de erro podem estar presentes, desde que identificados por

namespaces

vlidos.

Figura 16: Pacote SOAP contendo cabealho com informaes obrigatrias

Os tipos de dados suportados pela especificao padro e que permitem interoperabilidade entre as vrias implementaes SOAP so os citados a seguir:

O suporte do protocolo a valores escalares vlido conforme a tabela T2.

73

Type value xsd:int xsd:Boolean xsd:string xsd:float or xsd:double xsd:timeInstant SOAP-ENC:base64

Type 32-bit signed integer a boolean value, 1 or 0 string of characters signed floating point number date/time base64-encoded binary

Example -12 1 hello world -12.214 2001-03-27T00:00:01-08:00 eW91IGNhbid0IHJlYWQgdGhpcyE=

Tabela 2: Valores escalares suportados pelo protocolo.

Um valor tambm pode ser um struct, que definido por um XML que contm sub elementos. Structs podem ser aninhados e conter qualquer outros tipos, incluindo um array. Um exemplo de um struct pode se representado da seguinte forma, onde o nome dos elementos do struct so significativos, enquanto a posio, no.

<param> <lowerBound xsi:type="xsd:int">18</lowerBound> <upperBound xsi:type="xsd:int">139</upperBound> </param>

Um valor pode tambm ser um array, que definido por um elemento XML que o atributo SOAP-ENC:arrayType, o qual inicia com ur-type[, seguido do nmero de elementos do array, seguido de ]. Um array de quatro elementos pode ser representado dessa forma:

<parametro ENC:Array">

SOAP-ENC:arrayType="xsd:ur-type[4]"

xsi:type="SOAP-

74

<item xsi:type="xsd:int">12</item> <item xsi:type="xsd:string">Egypt</item> <item xsi:type="xsd:boolean">0</item> <item xsi:type="xsd:int">-31</item> </param>

A ordem dos elementos do array significativa enquanto os nomes dos elementos no. Se os elementos do array so do mesmo tipo o valor do elemento SOAP-ENC:arrayType determina o tipo dos sub elementos do array. Por exemplo, SOAP-ENC:arrayType="xsd:int[4]" representa um array de quatro elementos do tipo xsd:int.

Para arrays de tipos mistos o atributo SOAP-ENC:arrayType sempre deve especificar xsd:ur-type. Para arrays de tipos simples, o atributo xsi:type opcional para os sub elementos, mas sua incluso recomendada.

Um valor tambm pode ser um null , que especificado por um elemento XML com um atributo, xsi:null, cujo valor 1 e representado da seguinte forma:

<parametro xsi:null="1"/>.

3.4 Principais vantagens e limitaes

75

Ao tratarmos de vantagens e limitaes de protocolos de comunicao o mais importante saber qual o objetivo a ser atingido. Inmeros pontos podem ser abordados, mas sempre deve ser considerado que a natureza do sistema, a sua finalidade e o tipo do processamento a ser realizado que sero os fatores determinantes do sucesso ou no da utilizao de determinado protocolo de comunicao.

Considerando o exemplo de uma aplicao cientfica responsvel por coletar dados de sensores, realizar uma srie de clculos e que utiliza um banco de dados apenas como repositrio dos resultados obtidos, nesta aplicao um simples arquivo de log pode substituir um poderoso SGBD. J o mesmo no possvel quando tratase de uma aplicao onde o acesso a dados o pronto crtico do problema.

O mesmo raciocnio deve ser estendido utilizao do protocolo SOAP. Sero abordados a seguir comunicao: alguns quesitos-chave na utilizao de protocolos de

3.4.1 Tamanho da mensagem

Por encapsular os dados da aplicao em pacotes de arquivos XML as mensagens SOAP tendem a ser maiores que as mensagens de outros protocolos, como por exemplo IIOP, uma vez que, alm dos dados, o pacote XML contm em si a sua prpria estrutura que define a si e a informao que contm. Em aplicaes

76

onde o consumo de rede ou o tamanho da mensagem o ponto crtico, como apliaes wireless, por exemplo, o uso do SOAP deve ser meticulosamente avaliado. J em aplicaes que visam funcionar normalmente na web e com isso utilizando o protocolo HTTP, que baseado em texto, a utilizao do protocolo SOAP no deve representar uma perda significativa na performance da aplicao.

3.4.2 Complexidade de empacotamento

Comparado com a de outros protocolos, por exemplo, IIOP, a complexidade de empacotamento requerida pelo SOAP bem maior devido estrutura dos seus pacotes e apesar de mesmo sendo a linguagem XML to difundida e esse fato possibilitar o desenvolvimento de excelentes mecanismos de empacotamento de arquivos XML, este processo para o SOAP ainda ser mais dispendioso em termos de performance que para outros protocolos. Com isso, aplicaes distribudas de tempo real sofrero drsticos prejuzos caso se decida utilizar o SOAP, pois so mais sensveis ao grau de complexididade de empacotamento do protocolo. O mesmo problema no ser to sentido em aplicaes onde entrada e sada (I/O ) o ponto crtico ( I/O bound ).

3.4.3 Facilidade de depurao

77

Facilidade de depurao uma das caractersticas das mensagens SOAP mais apregoadas pelos defensores do protocolo. Sem dvida possibilita uma facilidade na correo de erros do sistema. Porm, em sistemas em produo, a depurao um processo que ocupa uma frao mnima do tempo total de execuo do sistema e que envolve poucos e especficos responsveis.

Penalizar o desempenho do sistema com a deciso de usar um protocolo de fcil depurao pode ser sem dvida uma falha grave de projeto, a ser sentida por toda a vida til do sistema. Esta tcnica poder utilizada em se tratando de prototipao do sistema, mas em tempo de execuo na produo pode representar um nus considervel em termos de performance. E, a depender do sistema, tornlo impraticvel.

3.4.4 Interoperabilidade entre sistemas

Estruturas de segurana estabelecidas na Internet (firewall), tendem a ser por natureza bastante seletivas no que diz respeito ao trfego de informaes atravs das mesmas. A utlizao de padres abertos e comercialmente difundidos um fator que possibilita aos pacotes SOAP trafegarem normalmente atravs de tais estruturas. Tal funcionalidade, aliada a mecanismos de segurana, como criptografia, representa uma economia significativa medida que dispensam canais especiais de comunicao para a interoperabilidade de sistemas. O prprio protocolo de transporte, responsvel por conduzir os pacotes SOAP, geralmente HTTP,

78

representa uma estrutura cmoda e consistente de transporte. Quando desejamos obter interao entre sistemas corporativos dentro da prpria estrutura da empresa, uma vez que temos acesso aos firewalls internos (se existirem ) com a possibilidade de alteraes das suas configuraes, pode ser mais rentvel em termos de performance do sistema utilizar um protocolo com melhor sintaxe de transferncia, como por exemplo JRMP(RMI) ou IIOP (CORBA). Em se tratando de sistemas distribudos atravs da Internet , SOAP ser sempre um candidato com grande vantagem.

3.4.5 Interoperabilidade com outros protocolos

A interao com outros protocolos uma possibilidade que resulta da natureza da estrutura do protocolo. Existem atualmente estudos avanados na integrao entre SOAP e protocolos de outras arquiteturas, como RMI e CORBA. Por exemplo sobre RMI existe inclusive um projeto desenvolvido pela Universidade de Indiana , nos Estados Unidos que uma implementao SOAP baseada em RMI, chamada XSOAP [SLOMINSKI 2001].

A interoperabilidade entre protocolos pode trazer funcionalidades extras ao sistema e uma economia considervel. Por exemplo, atravs da interoperabilidade IIOP/SOAP possvel fazer com que objetos CORBA possam interagir com servios na Internet atravs de firewalls, e da mesma maneira permitir que sistemas baseados em CORBA possam interoperar com sistemas de outras arquiteturas.

79

3.5 Problemas de interoperabilidade

Para garantir a definio de um protocolo mais leve e comercialmente mais atraente, a ltima especificao do protocolo SOAP submetida W3C contou com a colaborao de representantes de grandes corporaes, como Microsoft, IBM e Lotus, mas tambm de pequenas empresas, como por exemplo a UserLand. Este fato foi decisivo para o surgimento de uma especificao bem mais simples e enxuta que a anterior e cujo objetivo manter simples a implementao do protocolo.

Este fato deu origem a vrias implementaes comerciais e livres do protocolo SOAP, causando o surgimento de alguns problemas de interoperabilidade entre plataformas. Um fator adicional complicante a participao das grandes companhias no mercado, que tentam impor sobre os menores desenvolvedores, padres para o desenvolvimento de implementaes SOAP. Por exemplo, a

definio pela IBM do WSDL ( Web Services Description Language ). Estas camadas adicionais no tm sido bem aceitas por alguns desenvolvedores e algumas implementaes de frameworks SOAP simplesmente no se destinam utilizao do WSDL, como por exemplo o APACHE SOAP [APACHE 2001], enquanto outras so totalmente orientadas ao uso do mesmo, como o caso do GLUE [GLUE 2001]. Isto faz com que, por exemplo, a APACHE possua dois

frameworks para utilizao do SOAP: um orientado a WSDL, chamado AXIS [AXIS

2001], alm do APACHE SOAP que no utiliza e atualmente no pretende utilizar WSDL, segundo a documentao disponvel no

site

do

projeto

(http://xml.apache.org/soap/docs/index.html).

80

Segundo Dave Winer, membro da empresa UserLand e colaborador da especificao SOAP 1.1, como ele, muitos desenvolvedores no aceitam a imposio dos padres das grandes empresas sobre o desenvolvimento com SOAP e procuram alternativas para um aprimoramento da especificao SOAP de forma a prover solues robustas de interoperabilidade entre frameworks de fornecedores diferentes. Seja padronizando um modelo de envelope SOAP especfico para

permitir a utilizao do modelo XML-RPC tradicional com SOAP, seja documentando as principais implementaes SOAP e mecanismos especficos para

interoperabilidade entre as mesmas [WINER 2001].

Em contrapartida aos problemas de interoperabilidade entre os frameworks existem estudos em andamento sobre a interoperabilidade entre web services e objetos CORBA. Tais estudos visam possibilitar total interoperabilidade entre sistemas legados que utilizam CORBA com servios disponveis na internet, com o objetivo de reduo de custos da base instalada de equipamento e software nas empresas por intermdio da interao dos sistemas corporativos com web services. Esta interoperabilidade est sendo testada atravs de wrappers que so estruturas capazes de converter requisies recebidas via SOAP/HTTP em requisies ao ORB e vice-versa.

A figura 17 representa um objeto corba utilizando um ou mais web services, enquanto que a figura 18 representa um web service efetuando chamada a objetos CORBA. Em ambos os casos a estrutura intermediria, chamada wrapper, responsvel por converter requisies SOAP em requisies CORBA e vice-versa.

81

Figura 17 Objetos CORBA utilizando web services

Figura 18 Web services utilizando objetos CORBA

3.6 Principais projetos e empresas envolvidas

A primeira especificao do SOAP (1.0) submetida W3C era bastante complexa, contendo a definio de vrios recursos e servios agregados ao ncleo do protocolo. Esta caracterstica fez com que poucas empresas, como por exemplo,

82

Microsoft e IBM manifestassem interesse no mesmo. Posteriormente, com a submisso da especificao SOAP 1.1, que definia um protocolo bem mais leve, cujo objetivo era permitir a sua extensibilidade, SOAP se tornou um protocolo

particularmente atraente Atualmente outras grandes empresas possuem projetos utilizando o SOAP, como a HP e a Sun Microsystems. Este fato provocou um aumento significativo no nmero de projetos

Os projetos de utilizao do SOAP so representados pelas vrias implementaes SOAP j disponveis. Nem todas esto completas e a maioria ainda no est madura, uma vez que a arquitetura para a qual foram originalmente concebidos, os web services, ainda encontra-se em fase de amadurecimento. Algumas das implementaes SOAP disponveis so de domnio pblico, outras so comerciais. Mas, as implementaes que hoje se encontram em estado mais consistente possuem uma verso gratuita e outra comercial, como por exemplo o GLUE, da Electric Mind, e esta uma tendncia que deve ser adotada pela maioria das implementaes que conseguirem transpor este perodo inicial, conseguindo a simpatia dos desenvolvedores. A seguir, uma relao com as principais, dentre as mais de 60 ( sessenta ) implementaes SOAP disponveis:

83

PROJETO
CapeConnect SOAP Glue HP Web Services Beta Jbroker WebLogic WASP TRLSOAP Web Services Toolkit Microsoft SOAP toolkit Visual Studio .NET .NET Framework SDK X-Soap XSOAP Apache Soap JAXM AXIS ESOAP ZOAP SOAP::Lite

RESPONSVEL
Cape Clear Software The Mind Electric HP SilverStream Bea Systinet IBM IBM Microsoft Microsoft Microsoft xWareSoft Extreme! Computing Lab Apache Fundation Sun Microsystems Apache Project Embedding.net jBoss.org Paul Kulchenko

CATEGORIA
COMERCIAL COMERCIAL COMERCIAL COMERCIAL COMERCIAL COMERCIAL COMERCIAL COMERCIAL COMERCIAL COMERCIAL COMERCIAL LIVRE LIVRE LIVRE LIVRE LIVRE LIVRE LIVRE LIVRE

Tabela 3: Principais implementaes SOAP.

84

4 Exemplo de aplicao

A aplicao de exemplo tem por objetivo demonstrar a utilizaao do protocolo SOAP para proporcionar a interoperabilidade de sistemas feitos em arquiteturas diferentes de objetos distribudos. Consiste de um simples cadastro de clientes e cujo cdigo foi escrito utilizando o GLUE como implementao SOAP, a linguagem de programao Java e tecnologias da sua plataforma J2EE (Java Enterprise

Edition), sendo elas: JSP ( Java Server Pages) e EJB ( Enterprise Java Beans ), e
RMI.

Nesta aplicao de cadastro consideramos a necessidade de se fazer uma pequena validao prvia de uma das informaes fornecidas pelo cliente antes de cadastr-lo. No exemplo em questo trata-se do CPF. A validao feita atravs da utilizao de um web service simples, feito exclusivamente para esta finalidade e utilizando a linguagem de programao Java. As aplicaes, servio de cadastro e servio de validao de CPF, se comunicam utilizando o protocolo SOAP onde o

85

servio de cadastramento envia ao validador uma mensagem contendo o CPF do cliente a ser cadastrado e recebe de volta uma mensagem contendo a informao sobre a validade ou no do nmero do CPF informado.

Na estrutura dos servios so utilizadas as seguintes ferramentas:

Tom Cat : Servidor web e servlet engine. JBOSS : Servidor de aplicao ( Application Server ). GLUE : Implementao SOAP. Como SGBD foi utilizado o ORACLE.

O cenrio composto por dois ambientes distintos:

No primeiro ambiente (A) funciona uma aplicao desenvolvida em camadas, utilizando a linguagem de programao Java e as tecnologias de sua plataforma de desenvolvimento J2EE. Esta aplicao responsvel por receber e armazenar em banco de dados as informaes dos clientes.

No segundo ambiente (B) funciona o web service, escrito na linguagem de programao Java e utilizando o GLUE como implementao SOAP.

A estrutura do primeiro ambiente formada por uma estao servidora (1) contendo um servidor web / servlet engine ( Tom Cat ), onde ficam as home pages,

JSPs e um servidor de aplicao( JBOSS ), onde ficam as classes de transao que

representam as regras de negcio, e por uma segunda estao servidora (2)

86

contendo um servidor de aplicao ( JBOSS ), onde ficam os objetos responsveis pela persistncia dos dados dos usurios.

A estrutura do segundo ambiente composta apenas por uma estao servidora (3) onde funciona o web service responsvel pela validao dos nmeros de CPF.

Figura 19: Cenrio de execuo do exemplo de aplicao

87

Na estao cliente o usurio solicita o seu cadastramento fornecendo seus dados atravs do seu navegador web. Fornecendo a URL do web site onde est disponvel o servio de cadastramento ser exibida na tela do usurio a home page enviada pelo servidor web sob a forma de JSP. Aps o cliente informar seus dados, o browser do cliente os envia ao servidor web onde est o servio de cadastramento de clientes utilizando protocolo HTTP e a porta de comunicao 80 ( padro dos servidores web). Ao receber os dados do cliente o servidor web repassa o arquivo JSP para o servlet engine, que o processa, extraindo as informaes fornecidas pelo usurio e dando incio s validaes.

Para efetuar a validao do CPF feita a localizao e ligao ao servio de validao ( web service ) atravs da Internet. efetuada ento, a chamada ao mtodo responsvel por receber o CPF a ser validado. O retorno do mtodo representa se o CPF vlido ou no. Caso o web service retorne a informao que o CPF informado vlido, o servlet engine se comunica com o servidor de aplicao onde se encontra o objeto responsvel pela persistncia das informaes do cliente. feita a busca pelo objeto remoto ( lookup ) e, de posse da interface remota, feita a chamada para o mtodo responsvel por gravar em banco de dados as informaes do usurio cujo CPF foi validado com sucesso anteriormente.

A aplicao possui a opo de listar os clientes efetivamente cadastrados na base de dados.

O web service que fornece o servio de validao de CPF composto por uma classe (CpfImp) que disponibiliza os mtodos utilizados pela validao, conforme

88

ilustrado no apndice II. Esta classe contm a implementao dos mtodos definidos pela interface (Cpf) que implementa, conforme ilustrado no apndice I e utiliza uma classe (CpfCnpj) que contm as regras de validao de CPF, conforme ilustrado no apndice III. O diagrama de classes deste web service est representado na figura

20.

Finalmente o servio registrado e inicializado utilizando como implementao SOAP o GLUE, Conforme ilustrado no apndice IV.

Figura 20: Diagrama de classes do web service.

O cadastro de clientes implementado pela classe CadastrarCliente, que contm a implementao dos mtodos necessrios para as tarefas de localizao e utilizao dos objetos e mtodos envolvidos no procedimento de cadastramento de clientes, cuja aplicao tem o seu diagrama de classes demonstrado na figura 21.

O mtodo execute() est ilustrado no apndice V, pertence classe de transao CadastrarCliente e contm o procedimento principal do cadastramento

89

de clientes efetuando a chamada para os mtodos responsveis por cada etapa do processo.

Figura 21: Diagrama de classes da aplicao de cadastramento de clientes

A partir de um documento XML a transao obtm a informao de onde encontrar o web service de validao de CPF e onde encontrar os objetos de persistncia dos dados do cliente ( EJBs ). Um trecho deste documento XML est ilustrado no apndice VI.

O mtodo validarCPF(), ilustrado no apndice VII, responsvel pela ligao a um web service especfico para validao de CPF, tendo como um dos parmetros a URL do web service, obtida do arquivo XML, ilustrado no apndice VI, que contm

90

as

definies

da

aplicao.

No

exemplo

em

questo

esta

URL

http://wally/glue/urn:cpf.wsdl.

Uma vez que o CPF informado foi validado com sucesso, atravs do mtodo getInitialContext() ser feita a ligao ao servidor de aplicao que contm os objetos remotos. A implementao deste mtodo vai sofrer algumas modificaes a depender do servidor de aplicao utilizado. No exemplo em questo a implementao direcionada ao JBoss e utiliza a informao do servidor de aplicao obtida do arquivo XML que contm as definies da aplicao, conforme ilustrado no apndice VI que, neste exemplo tem valor "wally:1097". Aps a ligao ao servidor necessrio fazer a pesquisa para obteno da interface remota (ClienteHome) do EJB responsvel (ClienteBean) e executar a persistncia dos dados dos clientes atravs do mtodo create(). Este processo efetuado pelos mtodos ilustrados nos apndices IX e X, respectivamente.

91

5 CONCLUSO

Apesar do SOAP ser uma soluo para uma srie de problemas de integrao entre sistemas distribudos, uma viso crtica do protocolo envolvendo todos os aspectos da sua utilizao nos permite facilmente perceber que, embora possa trazer grandes benefcios de imediato, ele no a soluo para todos os problemas e a deciso de se utilizar o SOAP como protocolo de comunicao do sistema distribudo deve ser tomada somente aps uma cuidadosa avaliao da natureza e finalidade da aplicao, ambiente de execuo, tipos de processamentos envolvidos e recursos de equipamentos disponveis. SOAP no deve ser utilizado por se tratar de uma nova tendncia comercial suportada por vrias empresas e sim se os recursos que disponibiliza representarem um ganho efetivo em relao aos objetivos que se pretende atingir e ao cenrio j existente. Decises desse tipo devem ser tomadas em nvel de engenharia de software e devem contar com o envolvimento de todos os setores envolvidos no problema como, por exemplo, web design,

92

desenvolvimento, gerencia de dados e gerencia de redes. Uma deciso errada a esse respeito pode acarretar srios prejuzos empresa.

Com o estudo feito podemos tambm concluir que SOAP um protocolo que representa uma tecnologia definitiva como suporte interoperabilidade de sistemas distribudos. Porm, a sua maior aplicabilidade e o ponto onde seus recursos e sua funcionalidade se tornam evidentes, so na integrao de sistemas atravs da Internet. Por ter como caractersticas marcantes a simplicidade e extensibilidade o protocolo uma especificao ainda bastante indefinida em vrios pontos referentes ao quesito interoperabilidade. Este fato faz com que empresas comerciais tentem submeter o protocolo a camadas superiores definidas pelas empresas com o objetivo de criar uma arquitetura to bem definida quanto de carter extremamente comercial, fato que atualmente provoca divergncia entre os vrios segmentos de desenvolvedores, inclusive aqueles que colaboram com a especificao do projeto. Este ambiente provoca um impasse pois ao mesmo tempo em que o SOAP se firma como uma boa soluo para problemas antigos de interao entre diferentes sistemas, a especificao da estrutura do protocolo tende a sofrer alteraes a depender da reao do mercado e desenvolvedores, e assim cria-se a possibilidade de integrao entre diferentes sistemas distribudos porm nem sempre vlida para todos as implementaes de framework possveis no mercado.

Sem dvida, a posio do protocolo SOAP na arquitetura dos web services e a prpria definio da sua estrutura interna poder vir a sofrer mudanas motivadas pelo avano das discusses sobre interoperabilidade. Os investimentos em interoperabilidade certamente passaro a ocupar posio de destaque dentro da

93

evoluo do protocolo, merecendo especial ateno de grandes e pequenos desenvolvedores.

Por este trabalho abordar um tema relativamente novo e ainda em amadurecimento no cenrio do desenvolvimento de aplicaes distribudas, alguns itens mencionados nesta pesquisa podem ser objeto de trabalhos futuros. Podemos citar entre os principais: uma estrutura de segurana aplicada ao protocolo, independente da arquitetura de desenvolvimento e das camadas que vierem a compor esta arquitetura; um estudo especfico sobre a performance obtida com a utilizao do SOAP sobre TCP, UDP e protocolos superiores; a definio de um padro de compatibilidade, em nvel de protocolo, entre as vrias implementaes SOAP existentes e que possam vir a surgir ; e a descrio de um estudo de caso de uma empresa cujos servios estejam integrados e disponveis atravs da internet com a utilizao exclusiva de software livre, os benefcios obtidos e as dificuldades encontradas.

94

6 REFERNCIAS BIBLIOGRFICAS

[APACHE 2001] Apache SOAP v2.2 Documentation. 2001. The Apache Software Foundation. Disponvel on-line em : < http://xml.apache.org/soap/docs/index.html >. Acessado em 20 de Outrubro de 2001.

[AXIS 2001] NELSON, C., DAVIS, D., MATKOVITS, G., DANIELS, G., KOPECKY, J., SNELL, J., MITCHELL, K., DUFTLER, M., JELLINGHAUS, R., NEYAMA, R., RUBY, S., WEERAWARANA, S., GRAHAM, S., AMIRBEKYAN, V., CLOETENS, W., NAKAMURA, Y., NAGY, B., BUTEK, R., JORDAHL, T., LORITSCH, B., SRINIVAS, D., KUMAR, R., Axis User's Guide. Disponvel on-line em: <

http://xml.apache.org/axis/index.html >. Acessado em 2 de Novembro de 2001.

[BELL 2000] An Overview of the UNIX* Operating System.Disponvel on-line em: < http://unix.about.com/gi/dynamic/offsite.htm?site=http://www.bell%2Dlabs.com/histor y/unix/tutorial.html>. Acessado em: 10 de Novembro de 2001

[BOX 2000] BOX, D.,

EHNEBUSKE, D.,

KAKYVAYA, G.,

LAYMAN,

A.,

MENDELSOHN, N. , NIELSEN, H. F. , THATTE, S. , WINER, D., Simple Object

95

Access Protocol (SOAP) 1.1, 8 de Maio de 2000. Disponvel on-line em: < http://www.w3.org/TR/SOAP/>. Acessado em 19 de Novembro de 2001

[BRAY 2000] BRAY, T., PAOLI, J., McQUEEN C. M. S. ,MALER, E., Extensible Markup Language. 6 de Outubro 2000. Disponvel on-line em:

<http://www.w3.org/TR/2000/REC-xml-20001006>

[COSTA 1998] A. A., Desenvolvimeto de Sistemas com Objetos Distribudos . 1998, 47p. Monografia de Concluso de Curso. Universidade Tiradentes -UNIT.

[CHRISTENSEN 2001] Erik Christensen & Greg Meredith & Francisco Curbera & Sanjiva Weerawarana. Web services Description Language (WSDL) 1.1. Microsoft Corporation & IBM Research, 2001. Disponvel on-line em:

<http://msdn.microsoft.com/library/en-us/dnwebsrv/html/wsdl.asp>

[JOHNSTON 2001] JOHNSTON, J., Why Open Source Developers Should Care About

Web

services.

25

de

Maio

de

2001.

Disponvel

on-line

em:

<http://www.webservicesarchitect.com/content/articles/johnston01.asp>. em: 20 de Agosto de 2001.

Acessado

[FLURY 2001] FLURY, G., Web services and IBM. 25 de Maio de 2001. Disponvel on-line em: <www.theserverside.com>. Acessado em 20 de Agosto de 2001.

[GLUE 2001] Glue Users Guide. 2001. The Mind Electric. Disponvel on-line em : < http://www.themindelectric.com/products/glue/releases/GLUE1.3/docs/guide/userguide.pdf >. Acessado em : 22 de Outubro de 2001.

[GROSSO 2001] GROSSO, W., Java RMI,Outubro de 2001. ISBN 1-56592-452-5, 572p. Disponvel on-line em:

96

<http://www.oreilly.com/catalog/javarmi/chapter/ch10.html>. Acessado em 20 de Outubro de 2001.

[GUDGIN 2001] GUDGIN, M., HADLEY, M., MOREAU, J., NIELSEN, H. F. , SOAP Version 1.2 Messaging Framework. 2 de Outubro de 2001.Disponvel online em: < http://www.w3.org/TR/2001/WD-soap12-part1-20011002/>

[JAVA 2001] The Source for Java(TM) Tecnology. Disponvel on-line em:< http://java.sun.com/ >. Acessado em 15 de julho de 20001.

[JAVAWORLD

2001]

Java

World

July

2001.

Disponvel

on-line

em:http://www.javaworld.com/. Acessado em 25 de julho de 2001.

[LEYMANN 2001] LEYMANN F., Web services Flow Language - WSFL1.0 , Maio de 2001.187p. Disponvel on-line em: < http://www-

4.ibm.com/software/solutions/webservices/pdf/WSFL.pdf >. Acessado em 6 de Novembro de 2001.

[McLAUGHLIN 2001] McLAUGHLIN, B., Java and XML, 2nd Ed. 2a. Edio , Setembro de 2001, ISBN 0-596-00197-5 , 528p. Disponvel on-line em: <http://www.oreilly.com/catalog/javaxml2/chapter/ch12.html> . Acessado em 15 de Setembro de 2001

[NIELSEN 2001] NIELSEN, H. F., Introduction to SOAP, Disponvel on-line em: <http://www.w3.org/2000/xp/Group/Admin/minutes-oct1100/soap-xpwg_files/frame.htm#slide0188.htm>.Acessado em 08 de agosto de 2001

[OMG 2001] OMG Object Management Group. The Common Object Request Broker: Architeture and Specification. Revision 2.5, 2001. Disponvel on-line em: <http://www.omg.org/cgi-bin/doc?formal/01-09-01 >.

97

[ONJAVA

2001]

Web

services

Disponvel

on-line

em:

<http://www.oreillynet.com/pub/a/onjava/2001/08/07/webservices.html>. em 14 de Agosto de 2001

Acessado

[PAGNUSSAT 2001] PAGNUSSAT,T. M., Modelo CORBA. 2000, 10p, Monografia ( Concluso de Disciplina). Disponvel on-line em:

<http://www.sit.com.br/SeparataDIV0007.htm>. Acessado em 24 de Outubro de 2001.

[RAJ 2001] RAJ, G. S., A Detailed Comparison of CORBA, DCOM and Java/RMI. Disponvel on-line em: <http://www.execpc.com/~gopalan/misc/compare.html>.

Acessado em 25 de Outubro de 2001

[RAGGET 1998] RAGGET,D. , Le HORS A. , JACOBS, I. HTML 4.0 Specification , 24 de Abril de 1998. Disponvel on line em: <http://www.w3.org/TR/1998/REC-

html40-19980424>

[REYNOLDS 2001a]REYNOLDS. M., Microsoft and Web services. 4 de Julho de 2001. Disponvel on-line em: Acessado

<http://www.webservicesarchitect.com/content/articles/reynolds01.asp>. em: 2 de setembro de 2001.

[REYNOLDS 2001b] REYNOLDS. M., What Are Web services. 25 de Maio de 2001. Disponvel on-line em: Acessado

<http://www.webservicesarchitect.com/content/articles/reynolds02.asp>. em: 2 de setembro de 2001.

[RMI 1999] Java Remote Method Invocation. RMI Architecture and Functional Specification. Sun Microsystems, Inc.Disponvel on-line em:

<http://java.sun.com/j2se/1.4/docs/guide/rmi/spec/rmiTOC.html>

98

[SAGANICH 2001] SAGANICH, A. , Java and Web services, Part I. 7 de Agosto de 2001. Disponvel on-line em:

<http://www.onjava.com/pub/a/onjava/2001/08/07/webservices.html>. Acessado em 21 de Agosto de 2001.

[SHANNON 2001] SHANNON, B., Java 2 Platform Enterprise Edition Specification, v1.3,174p. 27 de Julho de 2001. Disponvel on-line em: < http://java.sun.com/j2ee/j2ee-1_3-fr-spec.pdf >. Acessado em 6 de Novembro de 2001.

[SHARKEY 2001] SHARKEY, K., SEELY, S., SOAP: Cross Platform Web Service Development Using XML, Ed. Prentice Hall , Agosto de 2001,ISBN: 0130907634

[SILBERSCHATZ 2000] SILBERSCHATZ, A., GALVIN, P., GAGNE, G., Applied Operating System Concepts, 2000, 840p., John Wiley & Sons Inc., ISBN: 0-47136508-4.

[SLOMINSKI 2001] SLOMINSKI, A., GOVINDARAJU, M., GANNON, D., BRAMLEY, R., Design of an XML based Interoperable RMI System: SoapRMI C++/Java 1.1. 29 de Maro de 2001.Disponvel on-line em: <

http://www.extreme.indiana.edu/soap/rmi/design/ >.Acessado em: 16 de Novembro de 2001

[SUN 2001] Sun Microsystems Inc. The J2EE Tutorial.2001.Disponvel on-line em: < http://java.sun.com/j2ee/tutorial/1_3-fcs/index.html>. Acessado em 19 de Novembro de 2001

99

[TECHMETRIX 2001] Modelos das arquiteturas RMI e CORBA. Disponvel on-line em: <http://www.techmetrix.com/lab/labindex.shtml>. Acessado em 26 de Outubro de 2001

[UDDI 2000] UDDI Technical White Paper. Ariba, Inc. IBM Corporation & Microsoft Coporation, 2000. Disponvel on-line em: <http://www.uddi.org>. Acessado em 5 de Novembro de 2001.

[W3C

2001]

World

Wide

Web

Consortium.

Disponvel

on-line

em:

<http://www.w3c.org>. Acessado em 25 de julho de 2001

[WINER 2001] WINER D., Unstalling SOAP. 29 de Maro de 2001. Disponvel online em: < http://davenet.userland.com/2001/03/29/unstallingSoap > . Acessado em 19 de Novembro de 2001.

100

7 ANEXOS

101

7.1 ANEXO I - Cdigo Fonte da aplicao

Quadro I: Interface que define os mtodos para validao de CPF

102

Quadro II: Classe que fornece o servio de validao de CPF

Quadro III: Trecho da classe que implementa a lgica de validao do CPF

103

Quadro IV: Classe que inicia e registra o servio de validao de CPF

Quadro V: Mtodo execute()

Quadro VI: Trecho do arquivo XML que contm as definies do projeto

104

Quadro VII: Mtodo que valida um CPF atravs de um web service

Quadro VIII: Mtodo getInitialContext()

Quadro IX: Mtodo que pesquisa determinado objeto no servidor de aplicao

Quadro X: Persistncia dos dados no SGBD atravs do objeto remoto