UNIVERSIDADE FEDERAL DE SANTA CATARINA
PROJETOS I
Nome: Rafael da Silva Rodrigues
Matricula: 0323839-3
Disciplina: Projetos I
Java Magazine – Edição 34
Entendendo Web Services (Da RPC à Service-Oriented Architecture)
Osvaldo Pinali Doederlein
A estrada até os web services
A origem dos Web Services vem de muito tempo atrás, dos anos 70. Nessa época,
as aplicações se comunicavam basicamente através de APIs de camada de transporte, como
por exemplo os BSD Sockets para TCP/IP. Atualmente, com java, essa técnica pode ser
utilizada com o uso da classes java.net.Socket e java.net.ServerSocket, porém é um modelo
bastante rudimentar e muito trabalhoso.
Posteriormente, com o avanço na programação distribuída, vieram os sistemas de
arquivos distribuídos e os bancos de dados em rede. NFS da Sun e SMB da Microsoft são
exemplos de sistemas de arquivos que tinham como objetivo permitir o acesso de arquivos
transparente através de outro computador conectado a mesma rede. Já os SGDBs (Sistemas
gerenciadores de banco de dados) compartilhavam os dados de forma mais estruturada do
que os sistemas de arquivo, entretanto com maior custo em desempenho. Outro problema
dessas tecnologias foi a falta possibilidade de chamadas de operações remotas, como
execução de SQLs.
Com o intuito de suprir a necessidade da invocação de operações remotas foi criado
o RPC (Remote Procedure Call). Ele nos trás um conceito muito importante, o conceito de
interfaces. As interfaces utilizam rotinas stubs e skeletons para fazer a comunicação
cliente/servidor. O stub são rotinas que ficam no cliente passando-se por um servidor e no
momento em que são acionadas, vão através da rede em busca do skeleton. O skeleton
possui a implementação real da operação desejada pelo cliente, ou seja, ele quem irá
executar a operação no servidor. No caso de necessidade do retorno de algum dado pela
operação, o skeleton devolve o retorno via rede para o stub que o repassa para o cliente. O
principal problema do RPC atualmente é fato dele ser da geração das linguagens
estruturadas, não sendo assim interessantes para o uso com C++, Smalltalk e Java.
Como evolução ao RPC, já adotando o paradigma de orientação objetos, surgiu o
CORBA (Common Object Request Broker Architecture), padronizado pela OMG (Object
Management Group). Ele possui o núcleo bem parecido com o RPC, já que usa o mesmo
príncipio, os stubs e os skeletons. Entretanto, ele prove melhorias ao modelo proposto
anteriormente, o COS (CORBA Object Services) é uma delas, trata-se de um conjunto de
serviços com objetivo de facilitar o desenvolvimento. Do COS, pode ser destacado o COS
Naming, que tem funcionamento semelhante ao JNDI do J2EE, sua função é basicamente
localizar e registrar objetos por nomes. Seguindo a linha de evolução com relação ao RPC,
o Corba também acrescenta dois conceitos importantes, o ORB (Object Request Broker)
que é um componente que pode ser adicionado à aplicação (biblioteca) e tendo como
função principal executar tarefas de gerenciamento tais como: administrar portas de rede,
garbage collection, etc. Além disso, outro conceito empregado foi o de bus(barramento)
onde a maioria das aplicações poderá assumir papel de cliente ou de servidor, dependendo
da situação, o que não acontecia no RPC.
Continuando com a história dos objetos distribuídos, para plataforma J2EE surge o
EJB (Enterprise Java Beans). Como aspectos positivos do EJB com relação ao
CORBA,vem:
a facilidade da implementação do serviço
com o uso do container J2EE resolve-se vários problemas, como o serviço de
nomes (JNDI) que está sempre disponível sem exigir burocracias como o COS
Naming do CORBA.
Porém um ponto que deixou a desejar foi a falta de interoperabilidade com outras
linguagens, fato consolidado no CORBA. Esse problema foi solucionado em grande parte
com o uso de RMI (Remote Method Invocation) sobre IIOP (Internet Inter-ORB Protocol).
O IIOP é o protocolo de transporte do CORBA, permitindo assim a interoperabilidade com
aplicações CORBA. Outro ponto importante a ser ressaltado é o fato de boa parte da infra-
estrutura dos containers J2EE serem baseados sobre o CORBA, o EJB depende de um ORB
CORBA completo para se comunicar, muitos servidores JNDI são um Naming Service do
CORBA disfarçado.
Entram os web services
Para muitos a explosão do interesse por web services, a partir de 2000 foi uma
surpresa, pois já existiam alternativas maduras como CORBA e EJB. Além disso, o
protocolo SOAP (Simple Object Access Protocol), proposto para o uso em web services,
possui o tamanho da mensagem bem maior e por conseqüência a velocidade de transmissão
era muito mais lenta do que o já consolidado IIOP.
Porém nota-se algumas semelhanças da arquitetura básica de web services com as
de objetos distribuídos:
O SOAP é um protocolo XML sobre HTTP. Porém o HTTP é um protocolo
implementado em cima do TCP/IP utilizado nas demais arquiteturas
As aplicações utilizam runtime que implementa a comunicação do SOAP
Pode ter serviços padronizados. O UDDI (Universal Description, Discovery and
Integration) é um exemplo disso, ele é um diretório que permite publicar e
localizar informações sobre os serviços disponíveis. Essas informações
descrevem o formato das mensagens esperadas por cada serviço, e ficam
armazenadas em documentos WSDL (Web Services Description Language).
Como problema das tecnologias CORBA e EJB, veio o alto acoplamento, pois ao
ver a necessidade de distribuir uma aplicação, como exemplo uma aplicação de compras,
seria preciso criar camadas de interfaces remotas com métodos para executar as operações
como: listar produtos, comprar produto, cancelar compra, etc. Com isso, o modelo de
classes fica exposto, permitindo ao desenvolvedor utilizar classes, fazendo com que a nova
aplicação fique “amarrada”, pois ao estar invocando os métodos das diversas interfaces,
fica evidente dependência com ela, caracterizando o alto acoplamento. Isso é ruim pois ao
necessitar de mudanças nas interfaces, as aplicações dependentes do aplicação distribuída,
irão perder a compatibilidade.
Já com web services, o acoplamento é diminuído, pois diferentemente das outras
tecnologias, a aplicação que irá consumir o serviço não precisará ter acesso ao modelo de
classes para invocar um método, basta apenas saber o nome do serviço e o parâmetros
necessários. Esse é o ponto forte dessa tecnologia.
O Protocolo SOAP possui duas grandes vantagens. A primeira destaca-se por serem
simples requisições HTTP (ou HTTPS), isso facilita seu trafego na rede por não terem
problemas com firewalls, ao contrário do CORBA que teve diversos problemas. Já a
segunda vantagem se diz respeito ao uso do XML para as mensagens. Ele é transformável e
auto-descrito, o que facilita a interoperabilidade com os demais sistemas. No entanto, o
SOAP peca no desempenho, comparado com os demais protocolos de aplicações
distribuídas (como IIOP, RMI/IIOP), o HTTP fica em desvantagem. O fato do XML ter um
formato de mensagem bem maior que os objetos Java ou CDR (Common Data
Representation) do IIOP, resulta na perda de desempenho. Porém, isso é contornado pelo
baixo acoplamento das aplicações que utilizam web services, pois comparado com CORBA
e EJB, o trafego de mensagens é bem menor, compensando assim na questão do tempo.
Outra questão importante a ser levantada é o fato de web services utilizarem
chamadas assíncronas, ou seja, após o consumidor chamar por um serviço, o fluxo da
aplicação continua normalmente, ao contrário de CORBA e EJB que são síncronos, isso
significa que ao invocar o método, a aplicação fica no aguardo até que o método termine o
processamento. Isso pode ser ruim quando um servidor precisa entrar em manutenção, no
caso de um EJB, ao chamar o método, ele ficará esperando o retorno e enquanto que o web
services irá organizar em uma fila as chamadas e continuará normalmente o fluxo da
aplicação.
A abreviação SOA (Service Oriented Architecture) tem tido grande difusão
ultimamente, ela nada mais é do que uma arquitetura orientada a serviços, ou seja, é a
disponibilização de serviços para o uso por outras aplicações. Esses serviços precisam ter
baixíssimo acoplamento, altíssima interoperabilidade e orquestração, características essas
que a tecnologia web services possui e a torna mais apta que as demais: CORBA e EJB
para ser utilizada no SOA.
Concluindo, web services tem se mostrado forte na área de aplicações distribuídas,
principalmente pelo fato de ter baixo acoplamento e ter alta interoperabilidade. Além disso,
o fato de enviarem suas mensagens em formato assíncrono e organiza-las em filas auxilia
no caso de falhas no servidor. O conceito de web services irá ajudar bastante no mundo das
aplicações distribuídas por focar em um modelo com baixo acoplamento, não abordado até
então. Isso certamente acarretará em pesquisas e por conseqüência novas idéias para área.