João Augusto Alves Pacheco - Universidade Federal de Uberlândia

Transcrição

Universidade Federal de Uberlândia
Faculdade de Computação
Programa de Pós-Graduação
Uma Abordagem para Desenvolvimento de Serviços Baseados em
Web Services
João Augusto Alves Pacheco
Uberlândia
Dezembro 2003
i
Dissertação de Mestrado
Uma Abordagem para Desenvolvimento de Serviços Baseados em
Web Services
Dissertação apresentada ao programa
de Pós Graduação da Faculdade de
Computação da Universidade Federal
de Uberlândia – UFU, como um dos
requisitos para conclusão do curso de
mestrado e obtenção do título de
Mestre.
©Todos os direitos reservados
ii
Os abaixo assinados, por meio deste, certificam que leram e recomendam
para a Faculdade de Computação a aceitação da dissertação intitulada “Uma
Abordagem para Desenvolvimento de Serviços Baseados em Web Services”
por João Augusto Alves Pacheco como parte dos requisitos exigidos para
obtenção do título de Mestre em Ciência da Computação.
Uberlândia, 19 de dezembro de 2003
Orientador :
____________________________________________
Prof. Dr. Pedro Frosi Rosa
Universidade Federal de Uberlândia UFU/MG
Banca Examinadora : ___________________________________________
Prof. Dr. José Gonçalves Pereira Filho
Universidade Federal do Espírito Santo UFES/ES
____________________________________________
Prof. Dr. Jamil Salem Barbar
Universidade Federal de Uberlândia UFU/MG
iii
Data: Dezembro de 2003
Autor: João Augusto Alves Pacheco
Título: Uma Abordagem para Desenvolvimento de Serviços Baseados em
Web Services
Faculdade: Faculdade de Computação
Grau: Mestre
Convocação: Dezembro de 2003
A Universidade Federal de Uberlândia possui permissão para distribuir e
ter cópias deste documento para propósitos exclusivamente acadêmicos, desde
que a autoria seja devidamente divulgada.
___________________________________
iv
Autor
O AUTOR RESERVA OS DIREITOS DE PUBLICAÇÃO, E ESSE
DOCUMENTO NÃO PODE SER IMPRESSO OU REPRODUZIDO DE
OUTRA FORMA, SEJA NA TOTALIDADE OU EM PARTES SEM A
PERMISSAO ESCRITA DO AUTOR.
Dedico esta dissertação à memória de
meu pai Paulo e irmãs Rita e Eliana, à
minha irmã Ana Maria, à minha mãe
Antonia, e em particular a minha
esposa Célia e filhos Breno e Rita, por
terem
sempre
acreditado
na
me
apoiado
realização
deste
trabalho.
João Augusto Alves Pacheco
v
e
Agradecimentos
Agradeço a todos, que direto ou indiretamente permitiram que eu concluísse este trabalho:
•
A DEUS por me conceder força, paciência e fé;
•
Aos professores da Faculdade de Computação pelo apoio e incentivo;
•
Aos técnicos administrativos da Faculdade de Computação pelo apoio administrativo;
•
Ao Prof. Flávio de Oliveira Silva pelo apoio e paciência na utilização das ferramentas
aqui necessárias;
•
Ao Prof. Adalton Lima de Aguiar pelo apoio e companheirismo de sempre;
•
A todos aqueles que acreditaram e confiaram em mim.
Obrigado.
vi
Glossário de Acrônimos
API
Aplication Program Interface
AXIS
Apache eXtensible Interaction System
B2B
Business to Business
B2BI
Business to Business Integration
CLR
Common Language Runtime
CPU
Central Processing Unit
CTS
Common Type System
CORBA
Commom Object Request Broker Architecture
DCOM
Distributed Component Object Model
DTD
Document Type Description
EAI
Enterprise Apllication Integration
EDI
Eletronic Data Interchange
EJB
Enterprise JavaBeans
EIS
Enterprise Information System
ERP
Enterprise Resource Planning
FTP
File Transfer Protocol
GUI
Graphical User Interface
HTTP
Hiper Text Transfer Protocol
ISO
International Standard Organization
IDL
Interface Definition Language
J2EE
Java 2 Enterprise Edition
JIT
Just in time
JRMI
Java Remote Method Invocation
JSP
Java Server Pages
vii
JVMs
Java Virtual Machines
MEPs
Message Exchange Patterns
MSIL
Microsoft Intermediate Language
OMA
Object Management Architecture
OMG
Object Management Group
ORB
Object Request Broker
PDA
Personal Digital Assistant
RDF
Resource Description Framework
RRL
Remote Reference Layer
RPC
Remote Procedure Call
SGML
Standard Generalized Markup Language
SMTP
Simple Mail Transfer Protocol
SOAP
Simple Object Access Protocol
SOA
Service Oriented Architecture
UDDI
Universal Description, Discovery and Integration
UML
Unified Modeling Language
URI
Unique Resource Identifier
URL
Unique Resource Location
VAN
Value Added Network
XML
eXtensible Markup Language
W3C
World Wide Web Consortium
WS
Web Services
WSA
Web Services Architecture
WSDL
Web Services Description Language
WSIL
Web Services Inspection Language
WS-I
Web Services Interoperability Organization
viii
Lista de Figuras
Figura 01 - O conceito de procedimentos -------------------------------------------------------23
Figura 02 - Um programa chamando um procedimento remoto --------------------------23
Figura 03 - Arquitetura JRMI --------------------------------------------------------------------25
Figura 04 - Componentes da OMA --------------------------------------------------------------26
Figura 05 - Uma requisição enviada através do ORB----------------------------------------27
Figura 06 - Arquitetura DCOM ------------------------------------------------------------------29
Figura 07 - Aplicações Multicamadas -----------------------------------------------------------31
Figura 08 - Servidor de Comunicação-----------------------------------------------------------33
Figura 09 - Camada Web e Aplicação J2EE ---------------------------------------------------33
Figura 10 - Camada de Negócios e EIS----------------------------------------------------------34
Figura 11 - Servidor J2EE e Recipientes -------------------------------------------------------35
Figura 12 - Infraestrutura, Linguagens e Ferramentas -------------------------------------36
Figura 13 - CLR (Common Language Runtime)-----------------------------------------------38
Figura 14 - Suporte a Multilinguagem ----------------------------------------------------------40
Figura 15 - Arquitetura Básica - Web Services ------------------------------------------------44
Figura 16 - Representação das pilhas de um Web Services ---------------------------------47
Figura 17 - Camadas da Pilha de Transporte -------------------------------------------------48
Figura 18 - Camadas da Pilha de Descrição---------------------------------------------------50
Figura 19 - Representação da Pilha de Descoberta-------------------------------------------53
Figura 20 - Representação de uma Arquitetura Completa ---------------------------------55
Figura 21 - Exemplo do uso de XML ------------------------------------------------------------57
Figura 22 - Estrutura de uma mensagem SOAP ----------------------------------------------58
Figura 23 - Exemplo de um Envelope SOAP --------------------------------------------------59
Figura 24 - Exemplo de uma Mensagem SOAP - Pedido -----------------------------------60
Figura 25 - Exemplo de uma Mensagem SOAP - Resposta---------------------------------61
Figura 26 - Modelo de um Documento WSDL ------------------------------------------------62
Figura 27 - Exemplo da principal estrutura de um documento WSDL ------------------63
Figura 29 - Exemplo da utilização de tipos-----------------------------------------------------64
Figura 30 - Exemplo de uma operação mensagem-------------------------------------------65
Figura 31 - Exemplo de uma operação Request Response-----------------------------------66
Figura 32 - Exemplo de uma operação Request Response-----------------------------------67
Figura 33 - Exemplo de definição de um serviço----------------------------------------------68
Figura 34 - Estrutura básica de um registro UDDI ------------------------------------------69
Figura 35 - Solução Proposta----------------------------------------------------------------------73
Figura 36 - Diagrama das operações dos Web Services --------------------------------------79
Figura 37 - Código XML para especificação do tipo Assinante----------------------------80
Figura 38 - Definição do array de objetos Assinante, e do array de Strings -------------80
ix
Figura 39 - Definição dos elementos na operação getAssinantesList -------------81
Figura 40 - Código WSDL da operação getAssinantesList -------------------------81
Figura 41 - Operações dentro do elemento <portType> ---------------------------------81
Figura 42 - Operação getAssinantesList ------------------------------------------------82
Figura 43 - Especificação do elemento <service> ----------------------------------------83
Figura 44 - Classes automaticamente geradas pela ferramenta WSDL2Java ----------83
Figura 45 - Web Service construído --------------------------------------------------------------85
Figura 46 - Aplicação Cliente ---------------------------------------------------------------------86
Figura 47 - Quadro Comparativo ----------------------------------------------------------------90
x
Resumo
A Internet desempenha nos dias de hoje um papel fundamental em qualquer
organização que queira manter-se no mercado. Fazer compras, cotação do dólar, reserva de
hotéis, são operações possíveis de serem executadas via Web.
Apesar do avanço tecnológico existem serviços que ainda não estão facilmente
disponíveis na Internet, como por exemplo, um serviço que cuide de todos os passos
necessários para validar o crédito de um comprador, antes de realizar a compra. Isto acontece,
porque desde o aparecimento das redes de computadores, a integração de aplicativos com
características totalmente heterogêneas, tem sido um enorme desafio, e foram várias as
tentativas realizadas para solucionar o desenvolvimento de aplicações distribuídas, desde
sistemas operacionais distribuídos, sistemas operacionais de redes, usando arquiteturas como
RPC (Remote Procedure Cal), ORB (Object Request Broker) e JRMI (Java Remote Method
Invocation).
Desta forma, a integração de aplicativos tem sido sempre deixada a cargo dos analistas
e programadores, talvez porque as interfaces de sistemas (principalmente aquelas para
integração de sistemas) são soluções proprietárias.
Web Services, ou Serviços Web, apesar de ser uma evolução das diferentes tecnologias
de comunicação em ambientes distribuídos, é voltada para uso na Internet, e uma solução para
as dificuldades de integração entre aplicações distintas, pois sua idéia básica é prover funções
(serviços)
que
possam
ser
acessados
por
outros
serviços
de
qualquer
lugar,
independentemente de suas características.
Com objetivos de verificar os resultados desta nova proposta de integração de serviços,
foi projetado, desenvolvido e implantado neste trabalho, uma cadeia de Web services
utilizando diferentes ambientes operacionais (Windows e Linux), a linguagem de programação
JAVA, o servidor de aplicações Apache Tomcat e a plataforma Apache Axis para
processamento das mensagens.
xi
Abstract
Any organization that intends to stay running in today’s rough market has got to
recognize the essential role that the Internet plays on it. Shopping, dollar exchanging or even
booking a hotel room are all things you can do at the “click of a mouse”.
In spite of the high-tech level achieved by online operations, some services are rarely
found over the web. For instance, it is hard to find a service that provides the way for a buyer
to validate its credit. The reason may lie in the difficulty on joining two totally different
applications, and many were the experiments trying to overcome this issue. Take for example
operational systems built up using RPC (Remote Procedure Call), ORB (Object Request
Broker) and JRMI (Java Remote Method Invocation). Maybe is why the cooperation between
two applications is becoming a task delegated to analysts and developers only.
Besides the fact that the web services were generated for being used on network
environments, it is mainly focused on Internet use, and maybe that is the solution for
overcoming the difficulty on joining two different applications. The basic idea behind the
“web services” is to provide services that can be accessed by any other services, no matter
where or when.
This work intends to verify the results of this new way of joining services, by
projecting, developing and experimenting web services chains using different operational
systems (such as Windows and Linux), the JAVA language, the applications server Apache
Tomcat and the Apache Axis for message processing.
xii
Sumário
AGRADECIMENTOS ------------------------------------------------------------------------------ VI
GLOSSÁRIO DE ACRÔNIMOS --------------------------------------------------------------- VII
LISTA DE FIGURAS ------------------------------------------------------------------------------- IX
RESUMO ---------------------------------------------------------------------------------------------- XI
ABSTRACT------------------------------------------------------------------------------------------ XII
SUMÁRIO ------------------------------------------------------------------------------------------- XIII
1. Introdução------------------------------------------------------------------------------------------17
2. Estado da Arte em Processamento de Informações --------------------------------------20
2.1 Operação Remota ------------------------------------------------------------------------20
2.1.1 Chamada a Procedimento Remoto ---------------------------------------------------21
2.1.2 JRMI (Invocação de Metodo Remoto em Java) ------------------------------------23
2.2 Objetos Distribuídos --------------------------------------------------------------------25
2.2.1 CORBA (Common Object Request Broker Architecture) ------------------------25
2.2.1.1 ORB (Object Request Broker) ---------------------------------------------------27
2.2.1.2 IDL (Interface Definition Language) -------------------------------------------27
2.2.2
DCOM (Distributed Component Object Model) -------------------------------28
2.3 Arquiteturas de Componentes para construção de Sistemas Distribuídos --29
2.3.1 Plataforma J2EE ------------------------------------------------------------------------30
xiii
2.3.1.1 Aplicações J2EE ------------------------------------------------------------------31
2.3.1.2 Clientes J2EE ----------------------------------------------------------------------32
2.3.1.3 Camada - Client--------------------------------------------------------------------32
2.3.1.4 Camada - WEB ---------------------------------------------------------------------33
2.3.1.5 Camada de Negócios -------------------------------------------------------------33
2.3.1.6 Camada - Sistema de Informações de Empresas (EIS)----------------------34
2.3.1.7 Recipientes J2EE ------------------------------------------------------------------35
2.3.2 Plataforma .NET ------------------------------------------------------------------------36
2.3.2.1 CLR (Linguagem Comum de Processamento) -------------------------------36
2.3.2.2 Suporte Multilinguagem ----------------------------------------------------------38
2.3.2.3 Montadores -------------------------------------------------------------------------38
2.3.2.4 Linguagem Intermediária---------------------------------------------------------38
2.3.2.5 Compiladores JIT------------------------------------------------------------------39
2.3.2.6 Desempenho------------------------------------------------------------------------40
2.3.2.7 Geração de Código usando UML -----------------------------------------------40
2.3.2.8 Componentes da Plataforma .NET ----------------------------------------------41
3. Web Services --------------------------------------------------------------------------------------41
3.1 Definição -----------------------------------------------------------------------------------42
3.2 Arquitetura Básica-----------------------------------------------------------------------43
3.2.1 Componentes ----------------------------------------------------------------------------45
3.2.2 Partes -------------------------------------------------------------------------------------45
3.2.3 Operações --------------------------------------------------------------------------------46
3.3 Arquitetura Estendida ------------------------------------------------------------------46
3.4 Pilhas de um Web Service ------------------------------------------------------------47
3.4.1 Pilha Transporte ------------------------------------------------------------------------48
3.4.1.1 Camada de Transporte ------------------------------------------------------------48
3.4.1.2 Camada de Empacotamento------------------------------------------------------49
3.4.1.3 Camada de Extensão --------------------------------------------------------------49
xiv
3.4.2 Pilha Descrição -------------------------------------------------------------------------49
3.4.2.1 Camada de Interface --------------------------------------------------------------50
3.4.2.2 Camada de Implementação-------------------------------------------------------51
3.4.2.3 Camada de Política ----------------------------------------------------------------51
3.4.2.4 Camada de Apresentação---------------------------------------------------------51
3.4.2.5 Relacionamento entre WS--------------------------------------------------------51
3.4.3 Pilha Agências de Divulgação-------------------------------------------------------52
3.4.3.1 Camada de Inspeção --------------------------------------------------------------53
3.4.3.2 Camada de divulgação ------------------------------------------------------------53
3.4.3.3 Camada de Descoberta------------------------------------------------------------54
3.5 Arquitetura Completa ------------------------------------------------------------------54
3.6 Tecnologias Padronizadas para Web Services ---------------------------------55
3.6.1 XML (eXtensible Markup Language) -----------------------------------------------55
3.6.1.1 Exemplo do uso de XML ---------------------------------------------------------56
3.6.2 SOAP (Simple Object Acess Protocol) ----------------------------------------------57
3.6.2.1 Exemplo de um Envelope SOAP------------------------------------------------59
3.6.2.2 Exemplo de uma Mensagem SOAP – Pedido e Resposta -------------------60
3.6.2.3 Seqüência de procedimentos -----------------------------------------------------61
3.6.3 WSDL (Web Service Description Language) --------------------------------------61
3.6.3.1 Definições --------------------------------------------------------------------------63
3.6.3.2 Tipos (Types)-----------------------------------------------------------------------64
3.6.3.3 Mensagens --------------------------------------------------------------------------64
3.6.3.4 Operações---------------------------------------------------------------------------65
3.6.3.5 Ligações-----------------------------------------------------------------------------66
3.6.3.6 Serviços -----------------------------------------------------------------------------67
3.6.4 UDDI (Universal Description, Discovery and Integration) ---------------------68
3.6.5 O modelo de Segurança e Qualidade de Serviço ----------------------------------69
3.6.5.1 Auditoria de defesa----------------------------------------------------------------69
3.6.5.2 Autenticação------------------------------------------------------------------------69
xv
3.6.5.3 Obrigação ---------------------------------------------------------------------------70
3.6.5.4 Permissão ---------------------------------------------------------------------------70
3.6.5.5 Política ------------------------------------------------------------------------------70
3.6.6 O modelo de Gerenciamento ----------------------------------------------------------70
3.6.6.1 Elemento Físico--------------------------------------------------------------------70
3.6.6.2 Capacidade de Gerenciamento---------------------------------------------------70
3.6.6.3 Configuração de Gerenciamento ------------------------------------------------71
3.6.6.4 Gerenciador-------------------------------------------------------------------------71
4. Estudo de caso -------------------------------------------------------------------------------------72
4.1 Cenário --------------------------------------------------------------------------------------72
4.2 Solução Proposta ------------------------------------------------------------------------72
4.3
Ambiente de Implementação ------------------------------------------------------------74
4.3.1 Fundação Apache -----------------------------------------------------------------------74
4.3.2 Apache Axis (Apache eXtensible Interaction System) ----------------------------74
4.3.3 TOMCAT --------------------------------------------------------------------------------76
4.4 Especificação da Cadeia de Web Services ------------------------------------------------76
4.4.1 Identificação dos Requisitos-----------------------------------------------------------77
4.4.2 Geração das especificações dos Web Services--------------------------------------79
4.4.3 Geração dos Códigos dos Web Services ---------------------------------------------83
4.4.4 Implantação dos Web Services -------------------------------------------------------84
4.4.5 Usando os Web Services ---------------------------------------------------------------85
4.5 Avaliação --------------------------------------------------------------------------------------86
5. Conclusões e Trabalhos Futuros -------------------------------------------------------------90
6.
Referência Bibliográfica ----------------------------------------------------------------------92
xvi
1. Introdução
Um fato comum na rotina de um fornecedor de produtos é o cliente realizar um
pedido ou uma compra direta, e o vendedor se deparar com a necessidade da aprovação
do crédito do cliente. Esta situação sempre existiu no mundo dos negócios, e bem antes
do uso da informática como facilitadora, ela era resolvida de alguma maneira.
Na maioria das vezes o problema é resolvido com uma verificação no histórico do
cliente, um telefonema a um sistema público de proteção ao crédito, uma consulta ao
departamento de crédito da empresa, etc. e, com base nas informações recebidas, o
fornecedor executa as operações necessárias para concretizar a operação de venda.
Apesar da evolução das tecnologias e o advento da informática, a rotina do
vendedor para aprovação do crédito do cliente não alterou muito, porém o volume de
dados (clientes, mercadorias, fornecedores, bancos, vendedores) cresce dia a dia,
necessitando de melhores recursos para armazenamento dos dados, rapidez de acesso e,
segurança na consulta às informações, para uma tomada de decisão mais acertada.
O avanço das tecnologias no mundo da computação permitiu que vários serviços,
que antes eram executados manualmente, fossem informatizados, e assim surgia também
um novo desafio que era a necessidade de integração das aplicações.
Na verdade, a necessidade de integração entre aplicações existe há,
aproximadamente, trinta anos, pois novas linguagens de programação, sistemas
operacionais, arquiteturas e equipamentos sempre surgem com a evolução das
tecnologias e, assim ganha-se em poder computacional, mas nem por isso diminuem os
problemas que a geração passada da área de desenvolvimento de sistemas enfrentava, e
hoje, continuam talvez até com maior complexidade, já que uma enorme
heterogeneidade de hardware e software coexiste dentro das organizações.
Ao mesmo tempo em que ocorriam evoluções nas arquiteturas das plataformas
computacionais, aconteciam também modificações consideráveis nas arquiteturas dos
sistemas, provocando a migração para arquiteturas distribuídas.
Um Sistema Distribuído, segundo Tanembaum, é aquele que executa processos
em um conjunto de máquinas sem memória compartilhada, máquinas estas que aparecem
como um único computador para seus usuários [06].
Em um sistema distribuído, existe a possibilidade de integração entre objetos
residentes em uma mesma máquina, ou em máquinas diferentes. Quando ocorre entre
máquinas diferentes, existe a necessidade da transferência de dados entre elas e, para a
realização de tal operação necessita-se da chamada de métodos remotos, que
corresponde a objetos comunicando-se como se estivessem em uma mesma máquina.
Com o objetivo de um melhor desempenho para as aplicações, surgiu a
necessidade de distribuição de processamento em um ambiente cliente/servidor, ou seja,
um modelo necessário para a execução de uma aplicação em qualquer lugar da rede.
Criou-se então o modelo RPC (Remote Procedure Call) [29], desenvolvido pela
Sun Microsystems, e que segundo Tanenbaum, é o método que permite aos programas
chamarem procedimentos localizados em outras máquinas, alicerçado no paradigma
cliente/servidor [06].
Disponibilizando suas interfaces, esse primeiro conceito de middleware [35]
tornou possível a execução de uma mesma aplicação em plataformas diferentes, e
inicialmente, sob o paradigma de programação estruturada, foi implantado em diversos
sistemas.
Com o advento do desenvolvimento orientado a objetos, surgiram novos
middlewares que se enquadravam nesse novo paradigma. Os mais conhecidos são a
CORBA (Commom Object Request Broker Architecture), DCOM (Distributed
Component Object Model) e RMI (Remote Method Invocation)
Porém,
essas
tecnologias
apresentavam
muitas
vezes
dificuldades
de
implementação que de algum modo limitaram seus usos. Algumas dessas dificuldades
são: dependência de redes de valor agregado (VAN – Value Added Network), custos
operacionais, falta de interoperabilidade, baixo desempenho, etc.
Diante do exposto, a integração dos diversos sistemas existentes torna-se
complexa, principalmente com os sistemas legados, e assim, são diversas tentativas para
a criação de padrões que possibilitem a integração dos vários sistemas, porém muitas
vezes sem o sucesso desejado, pois são inúmeras as tecnologias e somente um esforço
conjunto conseguiria um padrão.
Em 1998, o consórcio W3C (World Wide Web Consortium) iniciou um trabalho
de padronização de uma tecnologia para apresentação de dados denominada XML
(eXtensible Markup Language) [15], ou seja, uma linguagem para definir a estrutura das
informações na Web, através de marcadores (Markups).
Os desenvolvedores perceberam o potencial da XML para a integração de
sistemas, por se tratar de uma representação abstrata independente de plataforma e
orientada à descrição dos dados.
Em 1999 surge o protocolo SOAP (Simple Object Access Protocol) [14] criado
por Dave Winer da Useland Software, Bob Atikinson e Mohsen Al-Ghosein, ambos
engenheiros da Microsoft. Um protocolo simples, que utiliza chamadas de
procedimentos remotos (RPC), e formatação XML.
Em 2000, com a especificação do SOAP 1.1, a comunidade de tecnologia da
informação identifica uma nova maneira de publicar, localizar e chamar um serviço
através da Internet, independentemente de localização e características do software, ao
que denomina de Web Service ou Serviço Web.
Os objetivos deste trabalho são: apresentar os aspectos filosóficos e arquiteturais
de Web Services, implantar uma infraestrutura para o desenvolvimento e implantação de
uma cadeia de Web Services, e desenvolver um estudo de caso a fim de verificar os
verdadeiros avanços conseguidos com esse novo modelo de integração de aplicações.
O Capítulo 2 apresenta um breve histórico sobre as tecnologias criadas para o
desenvolvimento de sistemas distribuídos, tais como RPC, JRMI, CORBA, DCOM,
.NET, J2EE, etc;
O Capítulo 3 apresenta os aspectos filosóficos e arquiteturais de Web Services,
incluindo a arquitetura estendida e, uma abordagem dos padrões utilizados em seu
desenvolvimento: XML, SOAP, WSDL e UDDI;
O Capítulo 4 apresenta uma seqüência de procedimentos adotada para o
desenvolvimento e implantação de um estudo de caso, onde foi adotado o Web Service
como solução;
O Capitulo 5 apresenta as conclusões conseguidas ao final do trabalho e algumas
propostas para trabalhos futuros.
2. Estado da Arte em Processamento de Informações
Como já dito, segundo Tanenbaum, um Sistema Distribuído é aquele que executa
processos em um conjunto de máquinas sem memória compartilhada, máquinas estas
que aparecem como um único computador para seus usuários [06].
Os sistemas distribuídos apresentam vantagens advindas desta distribuição tais
como disponibilidade, desempenho, otimização de custos, distribuição de tarefas e,
escalabilidade. Entretanto, surgem as características não desejáveis tais como:
afastamento, concorrência, assincronismo, heterogeneidade e autonomia e, a fim de
diminuir tais efeitos, têm sido desenvolvido diversos modelos e arquiteturas.
Atualmente há uma tendência de construir sistemas abertos baseados em objetos
distribuídos, pois desta forma os projetistas podem desenvolver e implementar sistemas
mais rapidamente a partir do aproveitamento de objetos distribuídos disponíveis na rede,
e os fornecedores podem ofertar aplicações com recursos específicos,
como por
exemplo, cotação de preços de determinados itens, para algum cliente, com certa
quantidade desejada e com um determinado prazo de entrega.
A seguir é apresentado um histórico evolutivo das tecnologias desenvolvidas para a
criação de sistemas distribuídos.
2.1 Operação Remota
Um objeto distribuído é essencialmente um componente, uma peça de software
com inteligência auto contida, que pode interoperar com outros objetos distribuídos
através de sistemas operacionais, redes, linguagens, aplicações, ferramentas e
equipamentos diversos [08].
Objetos distribuídos não trabalham sozinhos, pois em princípio são construídos
para interagir com outros objetos e, para isto, existe a necessidade de arquiteturas que
torne isto possível.
Antes de comentarmos algumas arquiteturas mais utilizadas no mercado, é
importante examinarmos como se realiza uma chamada de procedimentos.
2.1.1 Chamada a Procedimento Remoto
O modelo de chamada a procedimento remoto ou RPC (Remote Procedure
Call) é baseado na necessidade de se executar um componente de uma aplicação em
qualquer local da rede e, para isto, utiliza uma construção tradicional de programação - a
chamada a procedimentos [29].
Na comunicação em um ambiente cliente/servidor, a solicitação RPC de um
determinado serviço de um componente de recurso (servidor) é emitida pelo componente
de processos (cliente), e o local do componente de recursos é transparente para o usuário
(cliente),
assim,
RPCs
fornecem
ferramentas
poderosas
e
necessárias
ao
desenvolvimento de programas distribuídos.
Existem três tarefas fundamentais realizadas por uma implementação RPC:
•
Localização ("Binding"): encontrar onde se localiza um procedimento ou
serviço remoto;
•
Comunicação: providenciar uma conexão de rede confiável que permita a
transmissão de requests e responses, que funcionará como um canal de
comunicação entre o cliente e o servidor;
•
Interface com o código do usuário: converter uma chamada de procedimento
em um bloco de dados (mensagem) para que possa trafegar através da conexão,
e remontar a mesma chamada de procedimento no outro extremo (remoto) a
partir desta mensagem.
No lado cliente, um procedimento Stub tem a mesma assinatura (nome, argumentos
e tipo de retorno) que o procedimento remoto, e sua função é empacotar os argumentos
em uma mensagem para ser enviada através do canal de comunicação.
Quando uma mensagem contendo os resultados enviados pelo servidor surge neste
canal, o Stub extrai o valor de retorno antes de passá-lo para o código que chamou o
procedimento.
O complemento do Stub, localizado no lado do servidor, é chamado de Skeleton e
sua função é converter as mensagens que chegam pelo canal de comunicação em
argumentos e, chamar as implementações dos procedimentos requisitados. Quando o
procedimento termina a execução, o valor de retorno é convertido em uma mensagem
que é remetida ao Stub cliente. A Figura 01 apresenta um modelo conceitual para
chamadas a procedimentos.
P ro g ra m a
P rin c ip a l
Pro ce d .
01
Pro ce d .
02
Pro ce d .
04
Pro ce d .
03
Pro ce d .
05
C o m p u ta d o r
Figura 01 - O conceito de procedimentos
RPC utiliza o mesmo comportamento procedimental de um programa
convencional, permitindo que procedimentos possam estar localizados em máquinas
distintas. A Figura 02 ilustra este conceito.
P ro g ra m a
P rin c ip a l
Pr o c e d .
01
Pro ce d .
02
Pr o c e d .
04
Pro ce d .
03
Pr o c e d .
05
C o m p u ta d o r A
Pro ce d .
06
Pro ce d .
07
C o m p u ta d o r B
Figura 02 - Um programa chamando um procedimento remoto
2.1.2 JRMI (Invocação de Metodo Remoto em Java)
Cada linguagem de programação implementa o mecanismo de RPC de uma
maneira e, o RMI nada mais é do que a implementação de RPCs em Java, ou seja, é uma
tecnologia de gerenciamento de objetos remotos, porém os objetos-cliente e os objetos–
servidor devem ser escritos obrigatoriamente em Java [24].
RMI é um mecanismo que permite a um objeto instanciado em uma Máquina
Virtual Java (interpretador de “bytecode”) invocar métodos de um objeto que foi
instanciado em outra Máquina Virtual Java, ou seja, como Java é uma linguagem
orientada a objetos, JRMI não realiza chamadas a procedimentos remotos, mas a
métodos de um objeto localizado em uma máquina remota.
O funcionamento do RMI consiste basicamente em dois programas, um
funcionando como cliente e outro como servidor. O servidor instancia objetos remotos, o
referencia com um nome e faz um "BIND" (ligação) dele numa porta, onde este objeto
espera por clientes que invoquem seus métodos. Já o cliente referencia remotamente um
ou mais métodos de um objeto remoto.
É tarefa do RMI, disponibilizar os mecanismos para que a comunicação entre cliente
e servidor seja possível.
Como pôde ser visto, o RMI nada mais é do que a implementação de RPCs em
Java, e por isto executa basicamente as mesmas três tarefas fundamentais que precisam
ser realizadas por uma implementação RPC:
•
Localizar Objetos Remotos: encontrar onde se localiza um procedimento ou
serviço remoto;
•
Comunicar-se com Objetos Remotos: providenciar uma conexão de rede
confiável que permita a transmissão de requests e responses, que funcionará
como um canal de comunicação entre o cliente e o servidor;
•
Carregar "bytecodes" de objetos móveis - Como o RMI permite que objetos
remotos sejam passados como parâmetros numa função, ele fornece os
mecanismos necessários para carregar o código dos objetos remotos.
O RMI usa o mecanismo padrão empregado em sistemas RPCs, para comunicar-se
com objetos remotos, que são "stubs" e "skeletons".
Além destes, mais duas camadas compõem uma arquitetura JRMI:
•
Camada de Referência Remota – Responsável pela interface para os Stubs e
Skeletons, mascarando as diferenças entre os diversos tipos de protocolos do
servidor;
•
Transporte - Manipula os detalhes da conexão e, providencia um canal de
comunicação entre as JVMs (Java Virtual Machines) que executam o código
cliente e o servidor;
A Figura 03 apresenta uma arquitetura JRMI com as três camadas:
stubs e skeletons, referência remota e transporte.
CL IEN T E
S ER V ID O R
S tu b s
S k e le to n s
C a m a d a d e R e f e r ê n c ia R e m o t a
S i ste m a
RM I
T ra n sp o rte
T ra n sp o rte
Figura 03 - Arquitetura JRMI
2.2 Objetos Distribuídos
Diante da necessidade dos computadores estarem em redes, formando assim um
ambiente computacional distribuído e possibilitando a troca de recursos e dados entre si,
foram criados alguns padrões de middleware como o CORBA, da OMG (Object
Managemennt Group), e o DCOM da Microsoft.
A proposta destes padrões é oferecer a possibilidade de interface e comunicação
de objetos para que estes possam se relacionar independentemente da forma como foram
implementados e da arquitetura à qual pertencem.
2.2.1 CORBA (Common Object Request Broker Architecture)
Gerado pelo consórcio OMG, com mais de 800 companhias associadas das mais
diferentes áreas (IBM, Canon, DEC, Philips, Sun, Apple, etc, além de respeitados
usuários como Citicorp, Britsh, Telecom, América Airlines, e outros), trata-se de um
importante projeto de arquitetura de objetos distribuídos. Por possuir seu próprio padrão
denominado DCOM, a Microsoft não faz parte deste consórcio [07] [05].
Suas especificações são escritas em uma linguagem de definição de interface
neutra chamada IDL (Interface Definition Language) [30], cuja gramática é um
subconjunto da linguagem C++, e que fixa as bases dos componentes utilizados por ela.
Tais componentes devem ter portabilidade para as linguagens, ferramentas, sistemas
operacionais e redes.
A IDL é utilizada para especificar interfaces entre o objeto servidor e o objeto
cliente que o chama, independente de sistemas operacionais e linguagens de
programação, para os serviços e componentes que residem em um barramento CORBA,
permitindo assim que objetos, clientes e servidores, escritos em linguagens totalmente
diferentes possam trocar interações.
A CORBA é uma arquitetura que provê uma estrutura para integração entre
objetos diferentes, entretanto, ele é apenas um pedaço de uma arquitetura denominada
OMA (Object Management Architecture) [27].
Conforme a Figura 04, seus principais componentes são:
•
Núcleo ORB (Object Request Broker) - manipula requisições entre objetos;
•
Serviços CORBA a Objetos - definem serviços ao nível de sistema que ajudam a
gerenciar e manter objetos;
•
Facilidades CORBA - definem facilidades e interfaces no nível de aplicação manipulação de dados e armazenamento;
•
Objetos de Aplicação - são os objetos no nível visível de aplicação.
O b je t o s d e
Ap lic a ç ã o
F a c ilid a d e s
CORBA
N ú c le o O R B
S e r v iç o s
a
O b je t o s
Figura 04 - Componentes da OMA
O ORB é o componente com maior responsabilidade dentro da arquitetura OMA,
pois permite que objetos façam e recebam requisições de métodos em um ambiente
distribuído heterogêneo.
A CORBA é uma especificação das interfaces do ORB, ou melhor, um modelo
concreto para a especificação abstrata disponível no documento que define a arquitetura
OMA.
2.2.1.1 ORB (Object Request Broker)
O ORB, é o componente mais importante da arquitetura CORBA, sendo suas
responsabilidades intermediar todas as transferências entre cliente e servidor, e fazer
com que a transação seja transparente para cada uma das partes durante todo o processo.
CLIENTE
OR B
IM P LEM ENTAÇÃO
do OBJETO
Figura 05 - Uma requisição enviada através do ORB
A Figura 05 apresenta uma requisição proveniente de um cliente, sendo enviada
pelo intermédio do ORB, a uma implementação de objeto. O ORB é responsável pela
localização do objeto ao qual se destina a requisição, assim como, o envio dos
parâmetros da requisição no formato aceito por este objeto. Também é função do ORB, o
retorno de parâmetros de saída da requisição para o cliente, se assim houver.
2.2.1.2 IDL (Interface Definition Language)
A função da linguagem de definição de interface da CORBA é descrever as
interfaces das implementações de objetos, acessadas por seus clientes. Uma interface
descrita em IDL especifica o formato das chamadas providas pelo objeto e cada um dos
parâmetros de entrada e saída necessários para efetuar a operação.
Para o cliente ou usuário, a interface representa uma necessidade, pois quando ele
envia uma requisição, uma resposta certamente deverá retornar. Porém, para aquele que
implementa o objeto, a interface representa uma obrigação, pois ele deve implementar,
em alguma linguagem, todas as operações especificadas na definição da interface.
As especificações IDL são formadas por: Definições de Tipos, Constantes,
Exceções, Módulos e Interfaces. Este conjunto de definições compõe um arquivo de
extensão .idl, que contém as informações necessárias para a interface entre o cliente e a
implementação do objeto, tendo como elemento intermediário o ORB.
2.2.2 DCOM (Distributed Component Object Model)
Desenvolvido pela Microsoft, trata-se de uma extensão do modelo de objeto
baseado em componentes (COM) voltado para ambientes de redes, e assim como
CORBA, separa a interface dos objetos da implementação requerendo que todas as
interfaces sejam declaradas usando a linguagem de definição de interface (IDL) [09].
Uma interface DCOM é um conjunto de chamadas de funções tecnicamente
denominadas como métodos e, assim como o CORBA, serve como ligação entre o
cliente e o servidor, pois, através da tecnologia DCOM, objetos realizam chamadas a
métodos de outros objetos remotos de maneira transparente.
As chamadas a métodos de objetos remotos se comportam para a aplicação
cliente, da mesma forma como se comportam chamadas a métodos de outros objetos no
mesmo processo ou na mesma máquina que hospeda a aplicação, o que difere e é
transparente, é que o programa executável remoto não se encontra no espaço de endereço
da máquina local, mas sim em uma máquina remota na rede local ou na Internet.
Para requisitar um serviço, a aplicação cliente faz chamada ao método
implementado pelo objeto remoto que age como o servidor no modelo cliente-servidor.
Os objetos DCOM não mantêm seu estado, ou seja, os clientes não podem
reconectar-se para a mesma instância de um objeto em uma conexão posterior, pois, os
objetos DCOM não possuem um identificador. O que de fato acontece é que os clientes
recebem um ponteiro para uma interface, com informações sobre a localização do objeto
na rede, e para acessar os métodos do objeto são realizadas chamadas indiretas aos
métodos expostos pela API (Application Programing Interface) do objeto.
Objetos DCOM podem ser escritos em diversas linguagens de programação tais
como: Java, C++, VB, Delphi, ou até mesmo Cobol.
O ORB DCOM gerencia as interfaces que os objetos expõe através de suas APIs
expressas em uma linguagem de definição especial que pode ser utilizada para descrever
os métodos implementados pelos objetos.
O funcionamento de um modelo de arquitetura DCOM é mostrado na Figura 06.
COM
Execução
Cliente
Prov edor
Segurança
DCE
RPC
Protocolo de Pilha
COM
Execução
Prov edor
Segurança
Componente
DCE
RPC
Protocolo de Pilha
Protocolo
de Rede
DCOM
Figura 06 - Arquitetura DCOM
2.3
Arquiteturas de Componentes para construção de Sistemas
Distribuídos
A Internet representa hoje um instrumento fundamental para qualquer empresa
que queira se manter no mercado competitivo e, estas mesmas empresas têm encontrado
nesta classe de ferramentas novas maneiras de conduzir seus negócios.
Em diferentes momentos, as empresas vêm explorando o potencial da Internet das
mais diversas formas e vivendo um novo modelo de organização. Realizar cotações e
compras on-line, controlar saldos bancários, leitura de jornais, notícias do tempo,
cotação do dólar, entre outras, são possibilidades disponibilizadas pela Web.
Entretanto, existem alguns serviços que ainda não estão facilmente disponíveis,
como: saber se um médico tem disponibilidade de consulta em determinado dia; se o
fornecedor tem em estoque o tipo de peça desejada pelo cliente; ligar o ar condicionado
de uma residência, a qualquer momento e de qualquer lugar, através de um dispositivo
inteligente.
Possivelmente, esses serviços podem ainda não estar disponíveis, por não
existirem padrões para integração de aplicações proprietárias, pois cada empresa possui
sua forma de armazenar, descrever e processar seus serviços, e assim, fornecedores de
tecnologias e empresas têm feito investimentos para adaptar sua infra-estrutura para
trabalhar neste novo cenário.
Dois modelos de plataformas para desenvolvimento de aplicações voltadas para
Internet têm sido testadas nos dias atuais. São eles: Java 2 Enterprise Edition (J2EE) da
Sun Microsystem e .NET da Microsoft, que apesar de terem sido idealizados com
princípios arquiteturais similares, foram construídos a partir de diferentes bases
filosóficas.
.NET tem seus objetivos dirigidos ao sistema operacional Windows com uma
linguagem proprietária, já o modelo J2EE tem seus objetivos adotados em padrões
abertos. Entretanto, ambas fornecem arquiteturas de componentes para a construção de
aplicações distribuídas, oferecendo recursos similares para o desenvolvimento de
aplicações Internet e Web Services.
2.3.1 Plataforma J2EE
A plataforma Java2 Enterprise Edition ou J2EE utiliza um modelo de aplicação
distribuída em multicamadas (multitier). A aplicação lógica é dividida em componentes
de acordo com sua função, e os vários componentes que compõem uma aplicação J2EE
são instalados em diferentes máquinas, dependendo do ambiente multicamada J2EE, ao
qual o componente da aplicação pertence [11].
A Figura 07 apresenta duas aplicações multicamadas, divididas conforme descrição
abaixo:
•
Client – Camada de componentes que rodam na máquina do cliente;
•
Web – Camada de componentes que rodam no servidor J2EE;
•
Business – Camada de componentes que rodam no servidor J2EE;
•
Enterprise Information System (EIS) – Camada de Softwares que roda no
servidor EIS.
Apesar das aplicações multicamadas J2EE consistirem de três ou quatro camadas,
elas são geralmente consideradas de três camadas, porque se encontram distribuídas em
três diferentes locais ou máquinas: Máquina Cliente (Camada Client), Máquina Servidor
J2EE (Camadas Web e Business) e, Máquina de Banco de dados ou Sistemas legados
para suporte (Camada EIS).
Contudo não é a distribuição em máquinas diferentes que a caracteriza como multicamada, mas sim o poder de abstração na fase de projeto, de poder quebrar o problema
em problemas menores.
J2EE
Aplicação 1
Aplicação
Cliente
J2EE
Aplicação 2
Páginas
HTML
Páginas
JSP
Enterprise
Beans
Base de
Dados
Enterprise
Beans
Base de
Dados
Camada
Cliente
Máquina
Cliente
Camada
WEB
Camada
Negócios
Camada
TIES
Máquina
Servidor
J2EE
Máquina
BD
Servidor
Figura 07 - Aplicações Multicamadas
2.3.1.1 Aplicações J2EE
São construídas essencialmente de componentes, que são unidades de software
com inteligência auto contida, e que podem interoperar com outros componentes através
de sistemas operacionais, redes, linguagens, aplicações, ferramentas e equipamentos
diversos.
Uma especificação J2EE define os seguintes componentes:
•
Aplicações cliente e applets - Componentes que rodam no cliente;
•
Java Servlet e Java Server Pages (JSP) - Componentes Web que rodam no
servidor;
•
Enterprise JavaBeans (EJB) - Componentes de negócios que “rodam” no
servidor.
Componentes J2EE são escritos em JAVA e são compilados da mesma forma que
qualquer outro programa da linguagem.
2.3.1.2 Clientes J2EE
Um cliente J2EE pode ser uma aplicação normal ou uma aplicação Web.
Clientes Web - Um cliente Web consiste de duas partes: Dynamic Web
Pages que contém vários tipos de linguagens markup (HTML, XML, e
outras), geradas pelos componentes Web residentes na camada Web, e um
Web Browser, que mostra as páginas recebidas do servidor.
Um cliente Web é algumas vezes chamado de thin client, por não realizar
algumas atividades como pesquisa a banco de dados, executar regras
complexas de negócios, ou conectar-se a sistemas legados.
Aplicações Cliente - Roda na máquina do cliente e provê recursos para os
usuários manipularem tarefas que necessitam de uma interface , como o
GUI (Graphical User Interface).
2.3.1.3 Camada - Client
A Figura 08 apresenta os vários elementos que podem fazer parte da camada
cliente.
O cliente se comunica diretamente com a camada de negócios (business tier)
que se encontra no servidor J2EE, ou através de páginas JSP ou servlets na camada Web,
se o cliente se encontra em um Browser
Camada
Cliente
Componentes:
Navegador Web
Páginas Web,
Applets e
JavaBeans
Camada
Web
Camada de
Negócios
Servidor J2EE
Figura 08 - Servidor de Comunicação
2.3.1.4 Camada - WEB
Componentes Web J2EE podem ser servlets ou páginas JSP . Servlets são classes
escritas em Java que dinamicamente processam requisições e constroem respostas.
Páginas JSP são textos baseados em documentos que executam com servlets, mas
permitem uma forma mais simples para criar conteúdos estáticos.
Assim como a camada cliente, mostrado na Figura 09, a camada Web pode
incluir componentes Java beans para gerenciar o recebimento e envio de mensagens para
o enterprise beans localizado na camada de negócios para processamento.
Camada Web
Aplicação
Cliente
Páginas
JSP
Componentes
JavaBeans
(Opcionais)
Componentes:
Navegador Web
Páginas Web,
Applets e
JavaBeans
Camada
de
Negócios
Servidor J2EE
Figura 09 - Camada Web e Aplicação J2EE
2.3.1.5 Camada de Negócios
O Código de Negócios, que é a lógica dos processos empresariais, de empresas
tais como:
Banco, Varejistas ou Financeira, é implementada por enterprise beans
rodando na camada de negócios.
A Figura 10 mostra como um componente enterprise bean recebe dados dos
programas dos clientes, processa (se necessário), e envia para a camada de informações
do sistema para armazenamento.
Camada Camada
Negócios
EIS
Ba se de Da dos e
Sistem as Le gados
Aplicação
Cliente
Entidade Be ans
Ses são Be ans
Com ponentes
JavaBea ns
(Opciona is )
P á gina s
JS P
Componentes:
Navegador Web
Páginas Web,
Applets e
JavaBeans
Servidor J2EE
Figura 10 - Camada de Negócios e EIS
Existem três tipos de Enterprise Beans:
•
Sessão Beans – Representa uma sessão finita com o cliente, ou seja, há o
estabelecimento da sessão, a fase de transferência de dados e quando há o
encerramento da sessão, os dados da sessão são perdidos;
•
Entidade Beans – Representa uma capacidade de comunicação que pode
armazenar os dados em uma fila de uma tabela do banco de dados.
•
Mensagens Beans – Combina serviços de uma sessão Bean e um Java Message
Service (JMS) , permitindo que um componente de negócio receba mensagens
JMS assíncronas, de uma entidade Beans.
2.3.1.6 Camada - Sistema de Informações de Empresas (EIS)
A camada EIS gerencia um sistema de informações entre empresas incluindo
sistemas de infraestrutura tais como ERP (Enterprise Resource Planning), CRM
(Customer Relationship Management) transações com mainframes, Sistemas de Banco
de Dados, e outros sistemas de informações.
2.3.1.7 Recipientes J2EE
São os responsáveis pela interface entre um componente e os clientes, provendo
serviços transparente para ambos. Antes que uma Web, entreprise bean ou, componente
de aplicação do cliente seja executado, ele precisa ser juntado ao J2EE e colocado dentro
de seu recipiente, pois são eles que disponibilizam serviços de suporte de customização
oferecidos pelo servidor J2EE como: Segurança, gerenciamento de transações,
conectividade remota.
A Figura 11 apresenta um servidor J2EE e seus recipientes.
S e rvidor J2EE
Na ve gador
Se rv le t
Aplica ç ã o
Cliente
Re cipie nte
Aplic a çã o
Clie nte
M áquina
Clie nte
Pá gina
J SP
R ec ipie nte W E B
Ba se de
Da dos
Em pres a
Be a n
Em pres a
Be a n
R ec ipie nte EJB
Figura 11 - Servidor J2EE e Recipientes
•
Servidor J2EE – Porção runtime da plataforma J2EE. Um servidor J2EE
disponibiliza EJB e Recipientes Web;
•
Recipiente EJB – Gerencia a execução dos Java Beans de empresas cação J2EE.
Beans de empresas e seu recipiente rodam no servidor J2EE;
•
Recipiente Web – Gerencia a execução das páginas JSP e componentes Servlets.
Web Componentes e seus recipientes rodam no servidor J2EE;
•
Recipiente da Aplicação do Cliente – Gerencia a execução dos componentes da
aplicação do cliente. Aplicação do cliente e seu recipiente rodam no cliente;
•
Recipiente Applet– Gerencia a execução dos Applets. Consiste de um Web
Browser e Java Plug-in rodando juntos no cliente.
2.3.2 Plataforma .NET
Um conjunto de tecnologias de software para conectar informações, pessoas,
sistemas e dispositivos [26].
Trata-se então de uma plataforma que permite o desenvolvimento de sistemas,
disponibilizando informações e interagindo com uma variedade de outras aplicações e
dispositivos na Internet, independentemente das plataformas ou linguagens utilizadas.
É suportado por um serviço de processamento denominado CLR (Common
Language Runtime) ou Linguagem Comum de Processamento, uma arquitetura básica
(framework base), linguagens e ferramentas, conforme Figura 12.
O processamento e as bibliotecas oferecem serviços às aplicações e são, por isso
muito úteis por pouparem tempo dos programadores e facilitarem a utilização de código.
VB
C++
C#
JScript
....
ASP.NET
Padrões
Windows
Dados e XML
Biblioteca Básica de Classes
Visual Studio .NET
Especificação de Linguagem Comum
Linguagem Comum de Execução
Figura 12 - Infraestrutura, Linguagens e Ferramentas
2.3.2.1 CLR (Linguagem Comum de Processamento)
A CLR é a infra-estrutura de base que executa as aplicações e permite que estas
interajam com os outros componentes da arquitetura, conforme apresentado na Figura 13
[25].
Converte a forma na qual os programas foram compilados, usando uma
linguagem intermediária, para o código de máquina, e fornece todos os serviços de
suporte necessários às execuções dos programas, como: gerenciamento de memória,
tratamento de exceções, compilação, segurança, etc.
Sucintamente, a CLR pode ser vista como a funcionalidade de execução, à qual a
arquitetura acrescenta as funcionalidades da infraestrutura.
Bib lio te ca Bá sica d e Cla sse s
S u p o rte
S u p o rte d e
L in h a
CO M Co n d u to r
V e rifica d o r
d e T ip o s
Co n tro le d e
Ex ce çõ e s
M e ca n ism o s
p a ra S e g u ra n ça
F e rra m e n ta s d e
V e rifica çã o
LI pa ra
Com pila dor
Na tivo
Ge r e nc ia dor
de Códigos
Cole tor
de Lix o
Ca rre g a d o r d e Cla sse s
Figura 13 - CLR (Common Language Runtime)
2.3.2.2 Suporte Multilinguagem
As máquinas virtuais desenvolvidas anteriormente pela comunidade de
linguagens de programação são orientadas a uma linguagem de programação. Alguns
exemplos são: Pascal Virtual Machine (UCSD 1 p-machine), Warren Abstract Machine
(para Prolog) e claro, Java Virtual Machine (JVM).
A filosofia destas máquinas virtuais é basicamente: tenho a minha linguagem;
quero uma máquina virtual para esta linguagem.
A grande diferença na CLR é atualmente o suporte a cerca de 22 linguagens,
incluindo C#, C++, Pascal, Java, Visual Basic, JScript, Cobol, Scheme, como ilustrado
no topo da Figura 14. A CLR também abrange os diferentes paradigmas de programação
nas linguagens atualmente suportadas: linguagens procedimentais, funcionais, orientadas
a objetos e lógicas.
2.3.2.3 Montadores
Depois de criado o arquivo de código, usualmente o que se faz é submetê-lo ao
respectivo compilador para gerar um arquivo executável (PE – portable executable) ou
uma biblioteca dinâmica (EXEs e DLLs no caso do Windows).
Os arquivos ditos “executáveis” do .NET não são código-máquina para serem
executados em uma CPU específica, o código gerado pelo compilador do .NET é um
código escrito em uma linguagem intermediária denominada MSIL (Microsoft
Intermediate Language), que posteriormente será colocada sobre o CLR para ser
processada em uma CPU, em semelhança à Máquina Virtual Java.
Cada arquivo contém uma parte de metadados, que serão usados pelo CLR para
carregar todas as classes e recursos que o arquivo necessita para tratar as questões de
segurança e alocação de memória necessária, etc.
2.3.2.4 Linguagem Intermediária
A compilação de código-fonte gera código intermédio denominado Microsoft
Intermediate Language (MSIL). A MSIL é independente da CPU e compreende tipos de
objetos, instruções que criam e iniciam objetos, invocam métodos sobre objetos e que
manipulam elementos de arrays diretamente.
A grande vantagem da MSIL está na sua portabilidade, pois não está presa a
nenhuma plataforma de CPU em particular, e isto significa que um arquivo PE que
contenha MSIL pode ser executado em qualquer CPU desde que o sistema operacional
nessa CPU abrigue a camada CLR da arquitetura .NET.
2.3.2.5 Compiladores JIT
As instruções MSIL não são executadas diretamente pela CPU, pois o CLR
compila estas instruções para instruções de CPU nativas.
Quando o CLR carrega uma classe, associa a cada método o código de ligação
(stub code). Quando um método é invocado, o código de ligação encaminha a execução
do programa para o componente responsável por compilar os métodos MSIL em código
nativo. Este componente é denominado Compilador Just-in-Time (Just-in-Time
Compiler - JITter).
Quando o JITter compila a MSIL de um método, o código de ligação é
substituído pelo endereço do código compilado, e assim, em invocações futuras, o
código nativo será executado sem envolver o compilador JIT no processo.
A CLR está dotado de dois compiladores JIT: o compilador normal e o
econômico (EconoJIT). O compilador normal examina a MSIL de um método e otimiza
o código nativo resultante e, o compilador econômico é usado tipicamente em máquinas
onde o custo de uso de memória e ciclos de CPU é alto, pois substitui simplesmente cada
instrução pelo seu código nativo respectivo. Por isso o compilador econômico é mais
rápido que o normal; no entanto, o código nativo produzido é significativamente menos
eficiente.
Tipicamente, na maioria das máquinas, o JITter é o normal. No entanto, para
máquinas de pequeno porte, como os PDAs, o JITter é o econômico, pois requer menos
memória para ser executado.
C#
IL
IL
C++
VB
JScript Outras
Base de Linguagens
para o IL
T em porary
IL
M etadata
Asp .Net
CLR
Carregador
de Classes
DLL/Legados/pre-JIT
DLL/Legacy/pre-JIT
Código
Nativ o
Verificador
M
MSIL
SIL
OptIL
EconoJIT
JIT
Código
Nativ o
Execução
Segurança
Figura 14 - Suporte a Multilinguagem
2.3.2.6 Desempenho
A diferença de desempenho pode ser observada, pois afinal código compilado
para uma plataforma de CPU específica simplesmente executa quando é invocado,
enquanto que no ambiente CLR a compilação acontece em duas fases.
Primeiro, o compilador passa pelo código fonte para produzir MSIL e só depois,
em runtime, compila a MSIL para instruções nativas, de forma a executar efetivamente o
código, o que requer mais memória e tempo de CPU.
2.3.2.7 Geração de Código usando UML
A linguagem de modelagem UML (Unified Modeling Language) [28] é o padrão
para modelar aplicações do .NET, o que torna possível fazer a correspondência direta
entre um desenho de modelo em UML e o código fonte em qualquer uma das linguagens
do .NET. É possível, por exemplo, modelar a estrutura global de uma aplicação em
UML e, pedir ao .NET para gerar o esqueleto da mesma no código-fonte desejado.
O reverse engineering também é suportado a partir de código-fonte pré-existente,
o que significa que o .NET consegue gerar um modelo em UML do nosso programa, a
partir do nosso código-fonte.
2.3.2.8 Componentes da Plataforma .NET
•
.NET Framework e Visual Studio .NET – São as ferramentas do desenvolvedor
usadas para construir aplicações e XML Web Services. A .NET Framework é o
conjunto de interfaces de programação que constitui o núcleo da plataforma
.NET. O Visual Studio .NET é um conjunto de ferramentas independente da
linguagem do desenvolvedor.
•
.NET Server Infrastructure - A Infra-estrutura para operar os XML Web Services
baseia-se no Sistema Operacional Windows e no .NET Enterprise Servers, um
conjunto de aplicações infra-estruturais para comercio eletrônico que opera os
serviços XML.
•
Building Block Services – Serviços que constituem um conjunto integrado de
XML Web Services pelo qual o usuário torna-se o centro e podendo controlar os
dados. Entre eles esta o Passport (para identificação do usuário) e serviços de
entrega de mensagens, arquivamento, gerenciamento das preferências do usuário,
alindamento e outras funções.
•
.NET Device Software – Constituído do Widows XP, Widows ME, Widows CE,
.NET framework e da .NET Compact Framework, possibilitando que toda uma
nova geração de dispositivos inteligentes para a internet operem no universo
.NET.
3. Web Services
A sobrevivência das empresas no mercado competitivo depende fundamentalmente
da estratégia competitiva e das parcerias comerciais entre si, pois nenhuma empresa
existe sozinha. As parceiras requerem além de um bom relacionamento comercial, a
integração de diversos processos compatíveis (B2BI – Business to Business Integration).
Dessa forma é fundamental que a integração aconteça da melhor forma possível,
ou seja, com velocidade, confiabilidade e segurança. Web Services tem despontado como
uma ferramenta importante neste cenário.
Um acontecimento fundamental para a consolidação deste novo conceito foi a
formação da WS-I (Web Services Interoperability Organization), com o objetivo de
padronização. O grupo reúne empresas tais como, IBM, Microsoft, SAP, BEA System,
Fujitsu e outras.
Outro fato a destacar é que este consórcio trabalha junto ao W3C (World Wide
Web Consortium), entidade responsável pela padronização de diversas linguagens e
protocolos de Internet, inclusive o SOAP (Simple Object Access Protocol) e de outros
padrões fundamentais para o desenvolvimento de aplicações distribuídas.
3.1 Definição
Há várias definições para Web Services, porém segundo a W3C Web Service
Architecture Working Group, que é parte da W3C Web Services Activity, Web Services
é [18]:
“Um software identificado por uma URI (Unique Resource Identifier), cujas interfaces
públicas e ligações são definidas e descritas usando XML e, sua definição pode ser
descoberta por outros softwares. Estes sistemas podem então interagir com o Web
Service de uma maneira prescrita por suas definições, usando mensagens em XML e
transportadas por um protocolo da Internet”.
Portanto, um WS é a comunicação transparente de máquina-para-máquina e
aplicação-para-aplicacão, e bastando para isto ser capaz de entender SOAP, XML,
WSDL (Web Services Description Language), uma linguagem que descreve parâmetros,
sintaxe e métodos, UDDI (Universal Description, Discovery and Integration) [23], um
diretório geral que se assemelha às páginas amarelas para descrição do serviço e HTTP
(Hyper Text Transfer Protocol), protocolo para transferência de hiper textos na Internet.
No centro desta iniciativa encontra-se o conceito de interoperabilidade conjunta,
ou seja, a capacidade de sistemas diferentes se comunicarem e compartilharem dados
sem estarem necessariamente ligados entre si.
Segundo a W3C Web Service Architecture Working Group, os Web Services
devem possuir uma Arquitetura Básica que descreva uma visão global da arquitetura, e
uma Arquitetura Estendida que apresenta como acrescentar características e
funcionalidades à uma Arquitetura Básica.
3.2 Arquitetura Básica
A arquitetura do Web Services coloca em relacionamento vários componentes e
tecnologias através da pilha da arquitetura do Web Services. Uma implementação válida
inclui “subsets” ou partes da pilha de protocolos, mas precisa no mínimo disponibilizar
os componentes básicos de uma arquitetura.
Uma arquitetura básica de um Web Services deve incluir no mínimo a possibilidade
de executar os seguintes serviços [18]:
•
Trocar mensagens;
•
Descrever o Serviço;
•
Publicar e Descobrir as descrições do serviço na WEB.
A arquitetura básica determina uma interação entre agentes de software (módulos de
programas que executam tarefas especificas) através da troca de mensagens entre o
requisitante e o fornecedor de serviços. Estes agentes podem executar ambos os papeis,
ou seja, de fornecedor ou requisitante. Os fornecedores tem a responsabilidade de
publicar e descrever os serviços que oferecem, assim como o requisitante deve possuir
ferramentas capazes de encontrar tais descrições.
O modelo básico de arquitetura representa a interação entre três partes:
•
Fornecedor do serviço;
•
Atividade de descoberta do serviço;
•
Requisitante do Serviço.
Isto implica na necessidade das operações de Publicar, Descobrir e Comunicar
(Publish, Find e Bind).
O fornecedor faz uma descrição do serviço para o Web Services e publica-o
diretamente para o interessado ou coloca-a em uma agência de serviços para ser
descoberto. O interessado então faz uso de uma operação de pesquisa para encontrar e
recuperar a descrição do serviço localmente ou na agência, e usa esta descrição para
trocar mensagens com o fornecedor e utilizar o serviço.
Fornecedores e Requisitantes (Providers/Requesters) interagem através da troca de
mensagens padrões (MEPs – Message Exchange Patterns) que define uma seqüência de
uma ou mais mensagens, trocada entre eles. A descrição do serviço, que pode ficar
armazenada em uma agência de publicação de serviços, inclui informações do tipo e da
estrutura dos dados, identificação das mensagens e endereço do fornecedor.
Os agentes de Software em uma arquitetura básica podem realizar uma ou todas as
seguintes tarefas [18]:
•
Requisitante do Serviço – Requisitar a execução de um WS;
•
Fornecedor do Serviço – Processar a requisição de um WS;
•
Agencias de Divulgação – Publicar a descrição de um WS.
Um agente de software pode agir em um ou múltiplos papéis, ou seja, como
requisitante ou fornecedor somente, em ambos requisitante e fornecedor, ou como
requisitante, fornecedor e divulgador.
Um serviço somente é solicitado após sua descoberta e solicitação da descrição do
serviço para contatos.
A Figura 15 ilustra uma Arquitetura Básica, onde o requisitante e um fornecedor
interagem baseados na informação de descrição do serviço publicados pelo fornecedor e,
descoberta pelo requisitante de alguma maneira.
Agências de
Div ulgação
Encontra
Cliente
Usuário do
Serviço
Descrição
do Serviço
Publica
Interage
Serviço
Fornecedor
do Serviço
Descrição
do Serviço
Figura 15 - Arquitetura Básica - Web Services
Para possibilitar a troca de mensagens Request/Response, a implementação de um
Web Service provê agentes de Software que funcionam como ambos, requisitante e
fornecedor, como mostrado na Figura 15.
O requisitante envia mensagens para o fornecedor, solicitando informações sobre
o serviço ou para executar uma operação, e recebe de volta uma mensagem contendo o
resultado da consulta ou da operação.
O fornecedor, por sua vez, recebe a requisição, processa a mensagem e envia uma
resposta de volta ao solicitante.
As tecnologias utilizadas neste tipo de operação incluem SOAP, WSDL e HTTP.
3.2.1 Componentes
•
O Serviço – Quando um Web Service tem sua interface descrita por um serviço
de descrição, sua implementação é o serviço. Um serviço é um módulo de
software disponibilizado na rede pelo fornecedor e, existe para ser invocado por,
ou para interagir com o serviço do requisitante. Ele pode também realizar funções
como um requisitante, usando outros Web Services em sua implementação.
•
Descrição do Serviço – Contém uma descrição dos detalhes de interface e
implementação do serviço. Isto inclui seus tipos de dados, operações,
informações de ligação e localização na rede.
A descrição completa pode ser feita com um conjunto de documentos XML e, ser
publicada diretamente para um determinado usuário ou em uma agência de
divulgação.
3.2.2 Partes
•
Fornecedor de Serviços – Visto sobre a perspectiva do negócio, este é o
proprietário do serviço. Visto sobre a perspectiva da arquitetura, esta é a parte da
plataforma que hospeda o acesso ao serviço. Pode também ser definida como o
ambiente de execução do serviço ou o recipiente do serviço.
•
Requisitante de Serviços - Visto sobre a perspectiva do negócio, este é aquele
que tem alguma necessidade a ser satisfeita. Visto sobre a perspectiva de
arquitetura, trata-se de uma aplicação que invocará ou dará início a uma interação
com o serviço. A solicitação do serviço pode ser feita por um browser, por uma
pessoa ou um programa sem a intervenção de um usuário.
•
Agência de Divulgação - Trata-se de um local que contém um conjunto de
descrições de serviços, possíveis de serem acessados, onde os fornecedores
publicam as descrições de seus serviços. Da mesma maneira, os requisitantes dos
serviços podem recorrer a outras fontes para obter uma descrição como: um
sistema de arquivo local, FTP site, URL.
3.2.3 Operações
•
Publicar – Para que possa ser acessado, um serviço precisa antes publicar sua
descrição.
•
Encontrar – Através desta operação, o interessado no serviço recupera sua
descrição diretamente ou através de pesquisa em um diretório pelo tipo do
serviço desejado.
Esta operação pode ocorrer em duas diferentes ocasiões, no momento do projeto
e desenvolvimento da aplicação ou na hora da execução da aplicação.
•
Interagir – Nesta operação, o interessado invoca ou inicia uma interação com o
serviço no momento da execução, utilizando os detalhes de ligação colocadas na
descrição do serviço para localizar, contatar, e invocar o serviço.
Exemplos de interação incluem: Mensagens simples one way, broadcast de um
requisitante para vários serviços ou, uma conversação multi mensagens. Qualquer
um destes tipos de operações podem ser, Síncronas ou Assíncronas.
3.3 Arquitetura Estendida
A
Arquitetura
Estendida
incorpora
serviços
adicionais,
aumentando
as
funcionalidades dos componentes da arquitetura básica [18]. Alguns serviços que podem
ser acrescentadas por meio de headers são:
•
MEP – Uma forma padrão de troca de mensagens entre dois serviços;
•
Autenticação – Um módulo SOAP com Username/Password;
•
Confidencialidade –
Um módulo SOAP que permite criptografar e
descriptografar;
•
Integridade - Um módulo SOAP que utiliza uma assinatura digital;
•
Rota – Uma especificação dos caminhos das mensagens entre os nós;
•
Segurança – MEP – Uma série de requisições entre os nós com um módulo
SOAP de reconhecimento;
•
Sincronismo – Define o tipo de interação entre as partes envolvidas;
•
Attachment – Um pacote com múltiplos documentos juntos.
A Figura 16 apresenta um diagrama de interação com as três pilhas de possíveis
serviços, onde algumas são realizadas por módulos SOAP e o gerenciamento através de
MEPs [18].
Empacotamento
Gerenciamento
Conversações
Transações
Cracterísticas
do Servico
Confiabilidade
Segurança
Assincronismo
Armazenamento
Roteamento
Coreografia
Registro
Esquema XML
Mensag. SOAP e Cabeçalho
Mensagens SOAP e
Cabeçalhos
WSDL
Inspeção
Transporte
Descrição
Descoberta
Figura 16 - Representação das pilhas de um Web Services
3.4 Pilhas de um Web Service
A fim de garantir a interoperabilidade entre as operações de Divulgação, Procura
e Interação em uma arquitetura orientada a serviços (SOA), técnicas e conceitos padrões
devem ser definidos para cada parte e tipo de interação, segundo a W3C Web Service
Architecture Working Group.
Existe uma série de conceitos envolvendo segurança, gerenciamento e qualidade
de serviço, que precisam ser colocados em camadas e, os vários serviços disponíveis em
cada camada podem ser ou não dependentes uns dos outros.
Um detalhe importante é que nas camadas inferiores das pilhas as tecnologias e
conceitos já estão mais amadurecidos e apresentam um alto nível de padronização se
comparados a maioria das camadas superiores. Provavelmente o uso dos Web Services
proporcionará um contínuo desenvolvimento e padronizações dos níveis mais altos das
pilhas.
3.4.1 Pilha Transporte
Responsável pela troca física de informações entre as partes, incluindo uma
variedade de meios de transporte, de empacotamento e extensão das mensagens.
A Figura 17 apresenta as camadas da pilha de Transporte [18].
Agências de
Div ulgação
Descrição
do Serviço
Encontra
Cliente
Usuário do
Serviço
Publica
Interage
Serviço
Fornecedor
do Serviço
Descrição
do Serviço
Extensão
Transporte
Empacotamento
Transporte
Figura 17 - Camadas da Pilha de Transporte
3.4.1.1 Camada de Transporte
Representa a tecnologia a ser utilizada para o transporte das mensagens entre as
partes envolvidas, e por isto:
•
Um Web Services tem de estar em uma rede acessível, para ser invocado,
•
Para acesso a um Web Services público, o HTTP é o protocolo padrão de
transporte em rede;
•
Outros protocolos de transporte também podem ser utilizados, tais como SMTP e
FTP;
•
Uma Intranet
pode utilizar protocolos proprietários, ou de fornecedores
específicos como o MQSeries, Corba etc;
A escolha do protocolo de rede a ser utilizado, depende inteiramente dos requisitos
da aplicação tais como: Segurança, Acessibilidade, Desempenho e, Confiabilidade.
3.4.1.2 Camada de Empacotamento
Representa a tecnologia a ser utilizada na construção dos pacotes que serão trocados
entre as camadas.
•
XML (eXtensive Markup Language) – tem sido amplamente adotada como base
de empacotamento das mensagens;
• SOAP (Simple Object Acess Protocol) – mecanismo simples, baseado em XML,
para criar pacotes de dados estruturados a fim de serem trocados entre aplicações
em redes.
3.4.1.3 Camada de Extensão
Construída sobre a camada de Empacotamento, representa a tecnologia a ser
utilizada para agregar informações adicionais às mensagens a serem trocadas entres as
partes envolvidas.
Estas informações fazem parte da estrutura do envelope SOAP, que define um
mecanismo para incorporar extensões à mensagem sob a forma de headers, como
módulos de roteamento, política, segurança etc.
3.4.2 Pilha Descrição
A camada para descrição do serviço é na verdade uma pilha de documentos
descritos usando XML Schema. É através desta descrição que o fornecedor comunica
todas as especificações para o interessado no Web Services.
A Figura 18 apresenta as camadas da Pilha de Descrição.
Agências de
Div ulgação
Encontra
Cliente
Usuário do
Serviço
Descrição
do Serviço
Publica
Interage
Serviço
Fornecedor
do Serviço
Descrição
do Serviço
Contrato em Nível de negócios
Contrato em Nível de Serviços
Descrição
Composição
Orquestração
Apresentação
Policy
Descrição da Implementação
Descrição da Interface
XML Schema
Figura 18 - Camadas da Pilha de Descrição
3.4.2.1 Camada de Interface
Escrito em WSDL, contém um resumo da definição do serviço, que poderá ser
consultado pelos usuários que pretendem implementá-los. O serviço de interface tem
elementos que incluem:
•
TYPE – Descreve os tipos de dados simples e complexos, contido nas
mensagens;
•
Message – Especifica quais tipos de dados XML constituem as
várias
partes
da mensagem;
•
PortType – Define as operações do Web Services. E as operações definem quais
mensagens XML podem aparecer nas mensagens de entrada, saída e erros;
•
Binding – Descreve os aspectos referentes a protocolo, formato dos dados,
segurança, e outros atributos para a interface de um serviço.
3.4.2.2 Camada de Implementação
Descreve como uma interface de serviço deve ser implementada
por um
fornecedor e, sua localização para uma possível interação. Contém os seguintes
elementos:
•
Port – Contém um endereço de rede (URL);
•
Service – Contém uma coleção de Ports.
As definições da interface juntamente com a definição de implementação,
compõem uma completa definição WSDL do serviço.
3.4.2.3 Camada de Política
Consiste de fatos ou afirmações e, regras que se aplicam a um particular WS.
Pode ser utilizado para descrever ou apontar para documentos que estejam associados ao
negócio, como produtos, senhas, política de segurança, atributos de qualidade do serviço,
etc.
3.4.2.4 Camada de Apresentação
Consiste de uma descrição a mais, que pode acompanhar a descrição do Web
Services, que definirá como apresentar um serviço para um usuário e quais serão as
interações entre ele e o serviço.
Esta descrição pode ser utilizada para apresentações que serão feitas em PDA’s,
Telefones fixos, Microcomputadores, etc.
3.4.2.5 Relacionamento entre WS
Existem dois tipos de relacionamentos entre WS:
•
Programado – cujas regras encontram-se definidas nas camadas de Composição
e Orquestração;
•
Contratual – cujas regras encontram-se definidas nas camadas de serviços de
Contratos e Negócios.
As camadas Orquestração e Composição, descrevem como a comunicação
colaboração e fluxos de dados devem ser feitos em um Service-to-Service.
•
Camada de Orquestração – Define a coreografia de relacionamento de Web
Services entre dois parceiros, para uma completa interação. Por exemplo, um
acordo que define as regras entre o comprador e vendedor, para recebimento e
envio de mensagens contendo, Ordem de Compra, de Pagamento, Fatura,
Relatórios de Contabilidade, etc.
•
Camada de Composição – Define uma forma de execução do Web Services,
dentro da própria empresa ou entre empresas diferentes.
3.4.3 Pilha Agências de Divulgação
Enquanto as três camadas inferiores da pilha identificam tecnologias para
negociações e interoperabilidade, a divulgação e a descoberta do serviço podem ser
implementadas com uma série de soluções.
Qualquer mecanismo que permita ao interessado ter acesso à descrição de um
serviço, e torná-lo disponível a uma aplicação, é qualificado como serviço de descoberta.
Alternativamente, o serviço pode ser encontrado no momento do projeto da aplicação ou,
em tempo de execução, usando um diretório WSDL local ou público. A Figura 19 [18]
apresenta as camadas da pilha de descoberta.
Descrição
do Serviço
Agências de
Div ulgação
Encontra
Cliente
Usuário do
Serviço
Publica
Interage
Serviço
Fornecedor
do Serviço
Descrição
do Serviço
Descoberta
Agências de
Divulgação
Publicação
Inspeção
Figura 19 - Representação da Pilha de Descoberta
3.4.3.1 Camada de Inspeção
Tecnologias como WSIL (Web Services Inspection Language) [22] oferecem
métodos de procura por Web Services através da criação de documentos contendo uma
lista de WSDL URLs e outros WSILs relacionados dentro de um domínio, podendo
também fazer referência a entradas UDDIs.
As especificações WSIL definem convenções para especificações de nomes e
locais de arquivos, para facilitar a procura, similar a um endereço Index.html.
3.4.3.2 Camada de divulgação
A descrição de um serviço pode ser gerada ou codificada manualmente e, depois
incluída em um UDDI. Existem ferramentas que geram partes da WSDL e da UDDI.
A divulgação da descrição pode ser feita de várias formas:
•
Direta - O fornecedor envia a descrição diretamente ao interessado, através
de E-Mail, CDROM, FTP, etc;
•
Registros UDDI - Podendo ser:
Serviços Internos - registro para aplicações internas do site (escolas,
empresas, etc);
Portal – para uso de parceiros ou sócios externos à empresa;
Catálogo de Sócios – empresas parceiras com serviços específicos;
e-Marketplace – quando o fornecedor deseja competir c/ outros WS.
3.4.3.3 Camada de Descoberta
O Requisitante do Serviço deve procurar pela descrição dos Web Services em
dois diferentes momentos do ciclo de vida de uma aplicação:
Projeto – Serão pesquisadas por tipos de interfaces que eles suportam;
Execução - Serão pesquisadas baseadas em como eles se comunicam, ou na
qualidade do serviço oferecido.
Estas descrições poderão ser localizadas em uma Web page (URL), um repositório,
registro UDDI, etc., e poderão também ser selecionadas por preço, proximidade,
qualidade, suporte, etc.
Uma vez encontrado o serviço desejado, o requisitante pode invocar o
processamento deste usando da descrição do serviço, para gerar requisições SOAP para o
Web Services.
3.5 Arquitetura Completa
A Figura 20 ilustra um completo conjunto de funções contidas em uma
arquitetura estendida de Web Services [18].
As funcionalidades incluem tecnologias adicionais nas seguintes áreas:
Transporte, Descrição e Agentes de Descobrimento. Inclui também conceitos de
Segurança, Gerenciamento e Qualidade de Serviços que se aplica a todos os
componentes da arquitetura.
Descoberta
Agências
Agências
de
de
Divulgação
Divulgação
Publicação
Inspeção
Contrato em
Nível de negócios
Contrato em Nível de Serviços
Esquema XML
Gerência
Apresentação
Policy
Descrição da Implementação
Descrição da Interface
Segurança
Descrição
Composição
Orquestração
Qualidade do Serviço
Contrato em nível de Negócios
Extensão
Transporte
Empacotamento
Transporte
Figura 20 - Representação de uma Arquitetura Completa
3.6 Tecnologias Padronizadas para Web Services
Para que as interações entre Web Services aconteçam com sucesso, existe a
necessidade do uso de tecnologias padronizadas para os protocolos e formatação dos
dados.
3.6.1 XML (eXtensible Markup Language)
Em fevereiro de 1998 o World Wide Web Consortium (W3C) divulgou a primeira
versão da linguagem Extensible Markup Language (XML) [16], voltada para a
construção de documentos Web [17].
O objetivo era permitir que fossem construídos documentos cuja informação
fosse estruturada, isto é, documentos que contivessem não só o conteúdo, mas também
indicações a respeito deste. Em outras palavras, XML passou a permitir a elaboração de
documentos que contenham não só dados, mas também metadados.
Desde então, XML passou a ser utilizada na construção de documentos Web e
tornou-se uma forma padrão para representação de dados estruturados, em que a maioria
das especificações de Web Services utiliza.
A linguagem XML tem algumas características como:
•
descrever o conteúdo do documento;
•
descrever os dados estruturados como : assunto, título, autor, referências, datas,
preço, etc.;
•
fazer uso de tags (palavras encapsuladas por sinais < > ) e atributos (definidos
com name = “value”);
•
não predefinir as tags. Tags são definidas sob demanda, bem como a própria
estrutura do documento;
•
qualificar a informação diferentemente do HTML [10] que serve para definir a
visualização da informação;
•
independer do sistema operacional, linguagem ou fonte de dados das aplicações
que o utilizam;
•
fazer uso do DTD (Document Type Description) ou XML Schema para
descrever os dados;
•
auto descrever os dados através de DTDs e XML Schema.
O XML é um subconjunto do SGML (Standard Generalized Markup Language)
[13], que foi definido em 1986 pela ISO (International Standardization Organization)
como padrão ISO 8879.
O XML define a estrutura das informações através da tecnologia de marcadores
(markups) flexíveis, permitindo a possibilidade de extensibilidade, ou seja, uma
flexibilidade quanto a definição dos marcadores. Este recurso permite ao usuário criar
marcadores de acordo com a sua necessidade, sendo no entanto importante entender que
o XML foi projetado para armazenar, transportar e trocar dados e não para apenas
visualizar dados.
3.6.1.1 Exemplo do uso de XML

<?xml version=”1.0”encoding=”ISO-8859-1”?>
<bilhete>
<to>João</to>
<from>Augusto</from>
<heading>Lembrete</heading>
<body>não se esqueça do futebol hoje às 19.00 hs</body>
</bilhete>
Figura 21 - Exemplo do uso de XML
Neste fragmento de código XML, tem-se que:
•
A primeira linha do documento é um comentário;
•
A segunda linha do documento, define a versão do XML e o padrão
de
codificação usado neste documento. Neste caso segue a especificação da versão
XML 1.0 e usa o conjunto de caracteres ISO-8859-1 (ASCII);
•
A próxima linha descreve o elemento raiz do documento – Tag bilhete;
•
As próximas 4 linhas definem 4 filhos do elemento raiz bilhete (to, from, heading
e, body);
•
E finalmente a ultima linha que determina o fim do elemento raiz – bilhete.
3.6.2 SOAP (Simple Object Acess Protocol)
Um protocolo simples para acesso a objetos, projetado para invocar aplicações
remotas através de RPC ou troca de mensagens, em um ambiente independente de
plataforma e linguagem de programação [19].
Trata-se, portanto de um padrão que pretende garantir a interoperabilidade e
intercomunicação entre diferentes sistemas, através da utilização da linguagem XML, ou
seja, um protocolo padrão para troca de mensagens. Suas principais características são:
•
Definido pelo consórcio W3C;
•
Protocolo baseado em XML para troca de informações em ambientes
distribuídos;
•
Padrão de utilização em construção de Web Services;
•
Normalmente utiliza o HTTP como protocolo de transporte;
•
Uma mensagem SOAP consiste basicamente dos seguintes elementos (vide
Figura 22):
o Envelope – Contém declarações de namespaces (uma coleção de
nomes, identificados por uma URI, que são utilizados em documentos
XML como tipos de elementos e nomes de atributos) e atributos
adicionais como o estilo de codificação (encoding style) que define
como os dados são representados no documento XML. É o elemento
raiz do documento e, obrigatório em toda mensagem.
o Cabeçalho – Um cabeçalho opcional, que carrega informações
adicionais, como por exemplo, se a mensagem deve ser processada por
um nó intermediário. Quando utilizado, deve ser o primeiro elemento
do envelope.
o Corpo – Elemento obrigatório no documento, e contém o payload, ou
a informação a ser transportada pela rede. Pode conter um elemento
opcional fault, utilizado para levar mensagens de status e erros
retornados pelos “nós” ao executarem a mensagem.
E n v e lo p e S O A P
C AB E Ç ALH O
C OR PO
Mensagem
F a lh a
Figura 22 - Estrutura de uma mensagem SOAP
Uma especificação SOAP, segundo a W3C, define as seguintes informações, como
necessárias em toda chamada RPC.
•
A URI do objeto alvo;
•
O nome do Método;
•
Os parâmetros do método (requisição ou resposta);
•
Uma assinatura do método opcional;
•
Um cabeçalho (header) opcional.
3.6.2.1 Exemplo de um Envelope SOAP
<!-- Versão do XML que esta sendo utilizada -- >
<?xml version=”1.0”encoding=”UTF-8”?>
<!--Prologo–Envelope SOAP–Define Namespaces XML Schema -- >
<soap:Envelope
xmlns:soap=”http://www.w3.org/2001/12/soap-envelope”
soap:encodingStyle= http://www.w3.org./2001/soap-encoding">
<soap:Header>
<t:Transaction
xmlns:m=http://www.ufu.com.br/transaction"
soap:mustUnderstand=”1”>234
</t:Transaction>
</soap:Header>
<soap:Body>
<m:Getnota xmlns:m=http://www.ufu.com.br/notas">
<m:Materia>Redes</m:Materia>
</m:Getnota>
</soap:Body>
</soap:Envelope>
Figura 23 - Exemplo de um Envelope SOAP
Neste envelope SOAP tem-se que:
•
A primeira linha do documento é um comentário;
•
A segunda linha do documento, define a versão do XML e o padrão
de
codificação usado neste documento. Neste caso segue a especificação da versão
XML 1.0 e usa o conjunto de caracteres UTF-8;
•
A próxima linha descreve o elemento raiz do documento – Envelope. Deve estar
sempre associado a um namespace;
•
A próxima linha define os tipos de dados usados no documento;
•
A próxima linha define um header com o elemento “Transaction”, um atributo
“mustUnderstand” com valor de 1, e um valor 234. Os atributos definidos no
Header, determinam como um recipiente deverá processar uma mensagem.
•
A próxima linha define o Body da mensagem. Observe que m:GetNotas e o item
Matéria são elementos específicos da aplicação. Eles não fazem parte do padrão
SOAP.
•
E finalmente a ultima linha que determina o fim do elemento raiz – Envelope.
3.6.2.2 Exemplo de uma Mensagem SOAP – Pedido e Resposta
<!--Prologo – Envelope SOAP – Define Namespaces XML Schema -- >
<soapenv:Envelope
xmlns:soapenv=”http://schemas.xmlsoap.org/soap/envelope/”
xmlns:xsd=”http://www.w3.org/2001/XMLSchema”
xmlns:xsi=”http://www.w3.org/2001/XMLSchema-instance”>
<soapenv:Body>
<add soapenv:encodingStyle
= http://schemas.xmlsoap.org/soap/encoding/">
<op1 xsi:type=”xsd:int”>20</op1>
<op2 xsi:type=”xsd:int”>50</op2>
</add>
</soapenv:Body>
</soapenv:Envelope>
Figura 24 - Exemplo de uma Mensagem SOAP - Pedido
<!--Prologo – Envelope SOAP – Define Namespaces XML Schema -- >
<soapenv:Envelope
xmlns:soapenv=”http://schemas.xmlsoap.org/soap/envelope/”
xmlns:xsd=”http://www.w3.org/2001/XMLSchema”
xmlns:xsi=”http://www.w3.org/2001/XMLSchema-instance”>
<soapenv:Body>
<addResponse soapenv:encodingStyle
= http://schemas.xmlsoap.org/soap/encoding/”>
<addReturn xsi:type=”xsd:int”>70</addReturn>
</addResponse>
</soapenv:Body>
</soapenv:Envelope>
Figura 25 - Exemplo de uma Mensagem SOAP - Resposta
3.6.2.3 Seqüência de procedimentos
Uma seqüência de procedimentos para solicitação de execução de um determinado
serviço, pode ter os seguintes passos:
1. Um software de e-commerce formata uma mensagem com a informação do
produto e do local de destino, na forma de uma mensagem XML;
2. A mensagem é encapsulada no formato SOAP, a fim de ser transportada pelo
protocolo HTTP, na Internet;
3. O Web Service “desempacota a mensagem” e a lê no formato XML, e em seguida
processa a solicitação;
4. O resultado é encapsulado pelo protocolo SOAP para ser transportado novamente
pelo HTTP de volta à origem.
3.6.3 WSDL (Web Service Description Language)
Os participantes de uma troca de mensagens em um Web Services necessitam ter
acesso a uma única descrição do serviço. O remetente precisa saber como formatar
corretamente a mensagem a ser enviada e, o receptor precisa da descrição do serviço
para entender como receber corretamente a mensagem.
Quando o remetente deseja enviar uma mensagem, ele obtém a descrição do
serviço e gera uma mensagem conforme o tipo de dados e estrutura contidas dentro de
um WSDL e, quando o receptor recebe a mensagem, ele a valida usando os mesmos
tipos de dados e estrutura contidas no serviço de descrição.
Portanto o WSDL pode ser entendido como uma linguagem para definição da
interface, baseada em XML, que possibilita a descrição das funcionalidades, métodos e
atributos, tipos de dados e os protocolos que podem ser utilizados pelos Web Services,
possibilitando assim, que outra aplicação possa compreendê-la e usar seu serviço [20].
Assim, trata-se de um documento XML que determina exatamente como uma
requisição e uma resposta SOAP serão realizadas. O modelo desta linguagem descreve
um documento como um conjunto de componentes com características próprias,
conforme visto na Figura 26 [21].
D E F IN IÇ Õ E S
T IP O S
M E N S AGE N S
OP E R AÇ ÕE S
L IG A Ç Õ E S
S E R V IÇ O S
Figura 26 - Modelo de um Documento WSDL
Um documento WSDL pode conter outros elementos, como elementos de
extensão e um elemento de serviços que torna possível agrupar várias definições de Web
Services em um único documento WSDL.
Exemplo da principal estrutura de um documento WSDL.
<definitions>
<types>
definição dos tipos……….
</types>
<message>
definição das mensagens……….
</message>
<portType>
definição de uma port……….
</portType>
<binding>
definição das ligações……….
</binding>
<services>
definição dos serviços……….
</services>
</definitions>
Figura 27 - Exemplo da principal estrutura de um documento WSDL
3.6.3.1 Definições
Elemento raiz do documento que contém o nome do WS e as definições de
namespaces. Trata-se de um recipiente com duas categorias de componentes:
•
Componentes WSDL – o qual define mensagens, interfaces, ligações e serviços
ou propriedades do local name, namespace name, children e attributes de um
elemento;
•
Tipos de componentes – são declarações de elementos e definições de tipos
retirados de algum sistema de tipos. Define as propriedades dos childrens e
atributos.
Exemplo do componente Definição:
<definitions
targetNamespace="xs:anyURI" >
<documentation />?
[ <import /> | <include /> ]
<types />
[ <message /> | <interface /> | <binding /> | <service /> ]
</definitions>
Figura 28 – Exemplo do componente Definição
3.6.3.2 Tipos (Types)
Contém os tipos de dados a serem utilizados na mensagem, e são definidos
utilizando o XML Schema. Os tipos aqui definidos serão utilizados dentro do elemento
mensagem para facilitar a interoperabilidade.
Exemplo da utilização de tipos:
<!---- Elemento Tipos -- >
<types>
<xsd:schema targetNamespace=”urn:EnderecoPesquisado1”
xmlns:xsd=http://www.w3.org/1999/XMLSchema”>
<xsd:simpleType name=”stateType”>
<xsd:restriction base=”xsd:string”>
<xsd:enumeration value =”TX”/>
<xsd:enumeration value =”IN”/>
<xsd:enumeration value =”OH”/>
</xsd:restriction>
</xsd:simpleType>
Figura 29 - Exemplo da utilização de tipos
3.6.3.3 Mensagens
Define os elementos de dados de uma operação. Cada mensagem pode consistir
de uma ou mais partes que podem ser comparadas a chamada de uma função em uma
linguagem tradicional de programação.
Cada elemento da mensagem pode ser utilizado como input, output ou fault.
Exemplo de uma operação mensagem :
<!-- Elemento Mensagens -- >
<message name=empty”/>
<message name =”AddEntryRequest”>
<part name=”name”Type=”xsd:string”/>
<part name=”address” Type=”typens:adress”/>
</message>
<message name=”GetAdressFromNameRequest”>
<part name=”name”Type=”xsd:string”/>
</message>
<message name=”GetAdressFromNameResponse”>
<part name=”adress” Type=”typens:address”/>
</message>
Figura 30 - Exemplo de uma operação mensagem
3.6.3.4 Operações
Descreve as operações oferecidas pelo Web Services e as mensagens que estão
envolvidas, por isto, é um dos mais importantes elementos do WSDL. Define o ponto de
conexão de um Web Services e pode ser comparado à biblioteca de funções em uma
linguagem tradicional de programação.
O tipo request/response é a operação mais comum, mas o WSDL define quatro
tipos:
•
One-way – A operação pode receber uma mensagem, porém não retornará uma
resposta;
•
Request/Response - A operação pode receber uma requisição e retornará uma
resposta;
•
Solicit-response - A operação pode enviar uma mensagem e aguardará por uma
resposta;
•
Notification - A operação pode enviar uma mensagem, porém não aguardará
uma resposta;
Exemplo de uma operação Request Response:
<!-- Exemplo de uma Operação -- >
<message name=”GetTermRequest”>
<part name=”term” Type=”xs:string”/>
</message>
<message name=GetTermResponse”>
<part name=”value” Type=”xs:string”/>
</message>
<portType name=”glossaryTerms”>
<operation name=”getTerm”>
<input message=”getTermRequest”/>
<output message=”getTermResponse”/>
</operation>
</portType>
Figura 31 - Exemplo de uma operação Request Response
Neste exemplo a port “glossary terms” define uma operação request-response
chamada “getTerm” . A operação “getTerm” requer uma mensagem de entrada chamada
“getTermRequest” com um parâmetro chamado “term” e, retornará uma mensagem de
saída chamada “getTermResponse”com um parâmetro chamado “value”.
3.6.3.5 Ligações
Bindings WSDL definem o formato da mensagem e detalhes de protocolo para o
Web Services. Este elemento possui dois atributos: o nome do atributo e o tipo do
atributo (name – type.)
O nome do atributo (pode-se usar qualquer nome) define o nome do Binding e, o
tipo do atributo faz referência a um portType já definido, para a ligação (binding).
O elemento soap:binding possui dois atributos – o estilo e o transporte. O estilo
pode ser um “RPC” ou “documento”. O transporte define o protocolo SOAP a ser
utilizado.
O elemento operation define cada operação que o port disponibiliza, e para cada
operação, a ação correspondente tem de ser definida. É necessário também ser
especificado como a input e output são codificadas.
Exemplo de uma operação Request Response:
<!—Exemplo de uma Operação -- >
<message name=”GetTermRequest”>
<part name=”term” Type=”xs:string”/>
</message>
<message name=GetTermResponse”>
part name=”value” Type=”xs:string”/>
</message>
<portType name=”glossaryTerms”>
<operation name=”getTerm”>
<input message=”getTermRequest”/>
<output message=”getTermResponse”/>
</operation>
</portType>
<bindingType name=”glossaryTerms”> name =”b1”>
<soap binding style=”document”
transport=http://schemas.xmlsoap.org/soap/http”/>
</operation>
<soap:operation
soapAction=http://example.com/getTerm”/>
<input>
<soap:body use=”literal”/>
</input>
<output>
<soap:body use=”literal”/>
</output>
</operation>
</binding>
Figura 32 - Exemplo de uma operação Request Response
3.6.3.6 Serviços
O componente Serviço descreve uma e somente uma interface que o serviço
provê, e contém os seguintes atributos: um porType (name) e um binding associado ao
mesmo.
O elemento possui uma tag informando a localização (location) do serviço, e
cada serviço contém um atributo name, indicando o nome do mesmo.
É possível ter diferentes ports para diferentes protocolos, mas todos acessando o
mesmo serviço.
Exemplo do elemento service
<definitions>
<service name="AdressBookService">
<port name="AdressBook"
bidigng="tns:AdressBookSOAPBinding”>
<soap:adress
location=http:localhost:8080/axis/services/AdressBook”/>
</port>
</service>
</definitions>
Figura 33 - Exemplo de definição de um serviço
3.6.4 UDDI (Universal Description, Discovery and Integration)
Ao se criar uma aplicação, são necessários mecanismos para catalogar e localizar
Web Services com funcionalidades específicas e que possam ser utilizadas pela aplicação
que está sendo criada. Da mesma forma que os anteriores, utiliza-se do padrão XML.
Trata-se de um serviço similar ao prestado pelas páginas amarelas, ou seja,
oferecem uma estrutura de informações na qual a empresa se auto registra e cadastra
seus respectivos serviços, através de suas definições na linguagem WSDL, separada por
área como, indústria, produto, localização geográfica, a fim de facilitar uma procura para
um interessado.
A Figura 34 apresenta uma forma básica de um registro UDDI. As informações
UDDI são classificadas em:
•
Páginas Brancas - Nome da empresa, informações de contato (nome, telefone,
fax...), tipo da industria;
•
Páginas Amarelas – Tipo da indústria, categoria do produto, localização
geográfica;
•
Páginas Verdes – Informações sobre os
serviços disponíveis, de ligações
(binding).
Desta forma, o UDDI especifica uma maneira de publicar e descobrir informações a
respeito de Web Services.
Brancas
UDDI
Amarelas
Verdes
Figura 34 - Estrutura básica de um registro UDDI
3.6.5 O modelo de Segurança e Qualidade de Serviço
WS reduzirão drasticamente o custo e o tempo de desenvolvimento das
aplicações, porém aumentarão consideravelmente o risco de segurança, e para isto
algumas precauções devem ser adotadas como uma política de segurança e qualidade do
serviço, recomendada pela WSA [33], para o bom funcionamento dos serviços.
3.6.5.1 Auditoria de defesa
Auditoria é um mecanismo implementado em beneficio do proprietário que
monitora um ou mais recursos, as ações relativas a um ou mais serviços e os agentes para
verificar se os compromissos foram satisfeitos. Tipicamente uma auditoria de defesa
monitora o estado de um recurso ou serviço, assegurando que a obrigação foi relaizada
com sucesso.
3.6.5.2 Autenticação
Um processo de verificação se um parceiro, em uma conversação, está habilitado
a representar uma pessoa ou organização. O domínio (conjunto de agentes e/ou recursos
que esta sujeito às restrições de uma ou mais regras de segurança) define o escopo da
aplicação das regras de segurança.
3.6.5.3 Obrigação
Uma obrigação é um tipo de segurança onde se o agente tem a responsabilidade
de realizar alguma ação, então ele é solicitado para executá-la. Quando a ação é feita,
então o agente pode dizer que foi satisfeita sua obrigação.
3.6.5.4 Permissão
Permissão é um tipo fundamental de segurança, pois quando um agente tem
permissão para fazer uma ação, para acessar algum recurso, ou concluir um certo
serviço, então espera-se que qualquer tentativa de executar a ação tenha sucesso.
3.6.5.5 Política
A política é uma descrição processável por computador, onde se encontram as
restrições dos procedimentos dos agentes de como devem executar suas ações e acessar
os recursos, ou seja, informam as permissões e obrigações dos agentes.
3.6.6 O modelo de Gerenciamento
Segundo a WSA [33], o modelo de gerenciamento foca os aspectos da
arquitetura referentes ao gerenciamento dos Web Services, em particular com ênfase no
uso da infraestrutura oferecida pelo WS para gerenciar os recursos necessários.
3.6.6.1 Elemento Físico
Um recurso físico é um recurso que existe no mundo físico, podendo ser um
agente, serviço ou descrição, que deve ser gerenciado.
3.6.6.2 Capacidade de Gerenciamento
Capacidade de gerenciamento são capacidades requeridas pelo gerenciador para
estar habilitado a efetivamente gerenciar. A chave da capacidade de gerenciar inclui a
habilidade para identificar o elemento gerenciável, a habilidade de conseguir
informações a respeito do elemento gerenciável, a habilidade para configurá-lo e a
habilidade de controlar seu ciclo de vida.
3.6.6.3 Configuração de Gerenciamento
A configuração de um gerenciamento é uma coleção de propriedades de
elementos gerenciáveis, ou seja, um conjunto de valores que denotam um estado
particular de um elemento.
3.6.6.4 Gerenciador
Um gerenciador é uma entidade que é capaz de realizar o gerenciamento de
elementos, ou seja, é um agente com habilidade de gerenciar um conjunto de elementos
gerenciáveis. Gerenciadores usam sua capacidade e interfaces para controlar o ciclo e
outras propriedades dos elementos gerenciáveis em beneficio dos proprietários dos
elementos.
Um gerenciador pode também ter capacidades adicionais dentro de sua arquitetura,
por exemplo, pode ter condições de diretamente controlar os recursos computacionais
que esta sendo usados pelos WS.
4. Estudo de caso
4.1 Cenário
Agências de turismos são constantemente consultadas, por seus clientes, com
relação a Hotéis, Restaurantes, Cinemas, Teatros, etc., bem como localização destes
estabelecimentos em determinada cidade.
Respostas a essas consultas nem sempre são totalmente satisfatórias como o
cliente gostaria, pois, se considerarmos que para manter uma base de dados atualizada é
necessário que os próprios estabelecimentos enviem regularmente para a agência os
dados que sofreram alterações, como, telefone, endereço, etc.
A idéia desse estudo de caso foi desenvolver uma cadeia de Web Services para
solucionar uma situação parecida com a descrita acima, e ao final retirar algumas
conclusões desta nova proposta de integração de serviços chamada Web Services.
Importante ressaltar que nenhuma metodologia específica para projeto e
desenvolvimento de sistemas foi utilizada, porém, baseada na própria experiência foi
adotada uma seqüência de procedimentos simples para a implantação do estudo de caso,
conforme poderá ser visto a seguir.
4.2 Solução Proposta
A solução proposta considera três atores distintos:
•
Uma Companhia Telefônica com sua base de dados contendo um grande número
de informações sobre seus assinantes e, com possibilidade de ser acessada via
Internet, aqui denominada Companhia Telefônica;
•
Uma empresa desenvolvedora de softwares e prestadora de serviços, responsável
pelo desenvolvimento dos Web Services, aqui chamada de Fornecedor;
•
Uma Agência de Turismo, com a necessidade de pesquisar informações sobre
Hotéis, Cinemas, Restaurantes, etc, existentes em determinada cidade e endereço,
aqui chamada de Usuário.
Fazendo uso deste serviço, o usuário terá em sua consulta as informações necessárias
sempre atualizadas, maior agilidade e, opções diferentes de pesquisa.
A Figura 35 apresenta uma visão topológica desta cadeia.
Ca de ia de W e b S e rvic e s
Aplic a ç ã o Us uá rio
(Applic a tion)
W e b S e rvic e s -P rove dor
(phone P rovide r)
W e b S e rvic e s
Com pa nhia Te le fônic a
(phone Lis t)
Ba s e de
da dos
Figura 35 - Solução Proposta
Conforme pode ser visto na Figura 35, um Web Service disponibilizará a base de
assinantes da companhia telefônica, para que o fornecedor possa realizar sua consulta.
Este Web Service foi chamado de phoneList e executou basicamente a seguinte
operação:
•
Informada uma cidade e um ramo de atividade, consultará a base de dados de
assinantes e retornará uma coleção de objetos que satisfaçam a consulta.
Um segundo Web Services instalado no fornecedor do serviço, receberá estes
dados da companhia telefônica e, fará uma filtragem nessas informações baseado na
consulta realizada pelo usuário. Este Web Service foi chamado de phoneProvider.
A Agência de Turismo ou usuário terá na sua aplicação a possibilidade de
consultas de diferentes formas, ou seja, com várias opções. O Ramo de Atividade e a
Cidade são campos obrigatórios, porém outras informações podem ser adicionadas a fim
de melhorar a consulta. São campos opcionais: o nome da rua e o bairro. Esta aplicação
do usuário foi chamada de application.
A fim de demonstrar a interoperabilidade, foram utilizados dois diferentes
sistemas operacionais. Uma máquina com o servidor Linux, onde se encontra o Web
phoneList e, uma outra com o Windows onde se encontra instalado o
Service
phoneProvider.
Nos servidores foi utilizado o Apache Tomcat como servidor de aplicações e, o
Apache Axis [02] como plataforma para o para processamento de mensagens SOAP.
A aplicação foi escrita em JAVA [12], utilizando as classes geradas pela
especificação WSDL phoneProvider e, as implementações dos serviços dentro de cada
servidor, também foram feitas em JAVA.
4.3 Ambiente de Implementação
Como a proposta deste estudo não é de avaliar ferramentas para desenvolvimento
de Web Services, então, foram utilizadas soluções disponíveis no mercado como
software livre. Especificamente soluções da fundação Apache e Java da Sun
Microsystems.
4.3.1 Fundação Apache
A fundação de software Apache [03] tem por objetivo oferecer suporte a toda
comunidade de desenvolvedores de projetos de software livres Apache. É formada por
grupos de voluntários cujo interesse é colaborar no desenvolvimento de softwares
através de suporte e contribuições aos projetos existentes na fundação. Seu projeto mais
conhecido é o Browser que leva seu nome.
4.3.2 Apache Axis (Apache eXtensible Interaction System)
Produzido pela fundação Apache [01], trata-se de um conjunto de ferramentas
escrito em JAVA, cuja proposta é fornecer uma infraestrutura para a construção e
manipulação de mensagens que utilizam o protocolo SOAP, ou seja, é um SOAP engine.
Além desta funcionalidade, o Axis disponibiliza uma série de outros componentes
que contribuem ao desenvolvimento de Web Services, são eles:
•
Um servidor simples que pode ser utilizado para testes;
•
Um servidor que pode ser instalado sobre o servidor de aplicações Apache
Tomcat;
•
Um amplo suporte à linguagem de descrição de Web Services (WSDL);
•
Ferramentas que geram classes JAVA à partir da especificação WSDL;
•
Alguns exemplos de programas;
•
Uma ferramenta para monitoração de pacotes TCP/IP (TCPMon).
Alguns recursos fundamentais também fazem parte do AXIS, e servem como
auxílio na sua utilização:
•
Suporte às versões 1.1 e 1.2 do SOAP;
•
Flexibilidade para configuração e desenvolvimento de sistemas;
•
Suporte a todos os tipos básicos para definição de serializadores e
deserializadores;
•
Serialização e deserialização automática de Java Beans;
•
Conversão automática, nos dois sentidos, entre coleções JAVA e arrays
SOAP;
•
Provedores para RPC e mensagens baseadas em serviços SOAP;
•
Geração automática de classes JAVA à partir de documentos WSDL;
•
Geração automática de documentos WSDL à partir de classes JAVA;
•
Geração automática de documentos WSDL à partir de serviços implantados;
•
Suporte para mensagens SOAP com anexos;
•
Provedor para acessar EJB´s (Enterprise Java Beans) como Web Services;
•
Servidor simples com suporte para http.
Algumas características do Axis que devem ser destacadas são:
•
Velocidade – O AXIS utiliza um analisador para conseguir um aumento
significativo em sua velocidade, em relação as versões anteriores do Apache
SOAP;
•
Flexibilidade – A arquitetura AXIS oferece enorme flexibilidade
para
inclusão de extensões nos cabeçalhos, gerenciamento de sistemas, etc;
•
Estabilidade – Define um conjunto de interfaces publicadas, que sofrem
poucas alterações;
•
Implantação orientada a componentes – Possibilita a reutilização de
manipuladores (Handlers) a fim de criar padrões para processamento de
aplicações;
•
Arquitetura de transporte – uma abstração simples para projetos de transporte
para emitentes e receptores de mensagens SOAP, sobre vários protocolos
como SMTP, FTP, etc;
•
Suporte à versão WSDL 1.1 que permite a construção de stubs para acessar
serviços remotos.
4.3.3 TOMCAT
Trata-se de um sub projeto do projeto JAKARTA [03], desenvolvido pela
Fundação Apache e é um servidor de aplicações que possibilita a execução de sistemas
na Internet.
Escrito em Java, e por isso faz uso das tecnologias da linguagem como Servlets e Java
Server Pages (JSP).
Como se encontra escrito em Java, para sua execução é necessário que no mesmo
computador esteja instalada uma versão runtime do J2SE (Java 2 Standard Edtion), para
execução dos programas escritos em JAVA.
O desenvolvimento de uma aplicação que utiliza o Tomcat como servidor exige
de seu desenvolvedor um conhecimento das linguagens JAVA, HTML e XML.
O servidor Tomcat converte automaticamente qualquer página JSP em uma
servlet equivalente, ou seja, ele é capaz de criar código fonte Java a partir de um
documento HTML. Servlet são classes escritas em Java cujos objetos têm a finalidade de
gerar documentos codificados em HTML. Uma página escrita em JSP (arquivos com
extensão .jsp) é uma página escrita em HTML e que contém pequenos fragmentos de
código Java e/ou tags especiais (definidos na especificação JSP).
4.4 Especificação da Cadeia de Web Services
A criação desta cadeia de Web Services, implicou na seqüência de procedimentos
abaixo:
•
Inicialmente foram identificados os requisitos necessários ao desenvolvimento da
aplicação;
•
Em seguida foram geradas as especificações dos Web Services usando para isto a
linguagem WSDL;
•
Depois foi realizada a geração dos códigos Java dos Web Services com a
ferramenta WSDL2Java [04] e a implantação dos Web Services;
•
Finalmente o uso dos Web Services construídos.
4.4.1 Identificação dos Requisitos
O primeiro elemento da cadeia, uma Agência Turismo, terá à sua disposição uma
aplicação escrita em Java a fim de facilitar sua consulta ao fornecedor do serviço. Esta
aplicação permitirá ao cliente realizar uma consulta com várias opções, onde,
obrigatoriamente deverão ser informados os campos de Ramo de Atividade e Cidade, e
opcionalmente Bairro e Rua.
Ao iniciar a aplicação, o sistema realiza automaticamente uma consulta ao
fornecedor do serviço, a fim de gerar uma lista dos Ramos de Atividades e Cidades
existentes na base de dados da Companhia Telefônica, e disponibiliza-a para o usuário
fazer sua opção.
Esta operação implicará na construção e envio, para o fornecedor do serviço, de
duas mensagens SOAP contendo a Cidade e Ramo de Atividade, respectivamente.
Estes procedimentos são realizados por duas operações chamadas getCidades() e
getRamosAtividades().
Tendo o usuário à sua disposição na tela da aplicação, todos os Ramos de
Atividades e Cidades, poderá melhorar sua consulta informando opcionalmente a Rua e
o Bairro. Será também permitido ao usuário informar somente parte dos campos, para
que o resultado da consulta contemple um maior número de objetos.
Estes procedimentos geram agora três mensagens SOAP com as possíveis opções
e, as operações são chamadas de getEmpresasCidade(cidade,ramoAtividade),
e
getEmpresasBairro(bairro,cidade,ramoAtividade)
getEmpresasRua(rua,cidade,ramoAtividade).
O Web Service do segundo ator (phoneProvider), considerado aqui o
fornecedor do serviço, ao receber as mensagens SOAP da aplicação do usuário, montará
uma nova mensagem SOAP com a Cidade e o Ramo de Atividade escolhidos pelo
usuário, e as enviará para o segundo Web Service (phoneList)localizado na
Companhia
Telefônica.
A
operação
é
chamada
de
getAssinantesList(cidade,RamoAtividade).
Ao receber o resultado obtido na consulta à base de assinantes, esta aplicação fará
um refinamento destas informações considerando as opções de Bairro e Rua feitas pelo
cliente, e em seguida, enviará o resultado para a aplicação do cliente.
No final desta cadeia encontra-se o Web Service instalado na companhia
telefônica (phoneList).Ele receberá do fornecedor uma mensagem SOAP contendo
a Cidade e o Ramo de Atividade, com o propósito de retornar uma lista com os dados
dos assinantes que satisfazem às informações contidas na mensagem.
Para isto, será feita uma consulta à base de assinantes da companhia, e montado
um array com o resultado, para ser enviado de volta ao fornecedor. Este array conterá
objetos da classe Assinante.
Na verdade este WebService realizará no início dos serviços, duas outras
operações. A primeira retornará para o fornecedor, um array de strings contendo as
cidades válidas e, a segunda um outro array de strings com os ramos de atividades,
também válidos, constantes da base de assinantes da companhia telefônica. Estas
operações são chamadas getCidadeList e getRamosAtividadesList.
O diagrama na Figura 36, apresenta uma visão da seqüência das operações
executadas na cadeia de Web Services.
Figura 36 - Diagrama das operações dos Web Services
4.4.2 Geração das especificações dos Web Services
Considerando atendido todos os requisitos necessários, o próximo passo é criar as
especificaçõe de cada Web Service, usando para isto a linguagem WSDL.
Inicialmente é necessario definir os tipos de dados complexos envolvidos nas
operações. Neste caso precisamos das informações referentes ao Assinante, a
definição de um array dos objetos e um array de strings.
O tipo Assinante será especificado com o seguite codigo XML:
<xsd:complexType name=”assinante”>
<xsd:all>
<xsd:element name=”sNome” type=”xsd:string”/>
<xsd:element name=”sFone” type=”xsd:string”/>
<xsd:element name=”sEndereco” type=”xsd:string”/>
<xsd:element name=”sBairro” type=”xsd:string”/>
<xsd:element name=”sCidade” type=”xsd:string”/>
<xsd:element name=”sRamoAtividade” type=”xsd:string”/>
</xsd:all>
</xsd:complexType>
Figura 37 - Código XML para especificação do tipo Assinante
O array de objetos Assinante e o array de strings são também definidos com
a linguagem WSDL, conforme pode ser visto abaixo.
<schema xmlns=”http://www.w3.org/2001/XMLSchema”
targetNamespace=”http://soapinterop.org/xsd”>
<import namespace =
http://schemas.xmlsoap.org/soap/encoding/”/>
<complexType name=”ArrayOfAssinante”>
<complexContent>
<restriction base=”SOAP-ENC:Array”>
<attribute ref=”SOAP-ENC:arrayType”
wsdl:arrayType=”typens:assinante[]”/>
</restriction>
</complexContent>
</complexType>
<complexType name=”ArrayOfString”>
<complexContent>
<restriction base=”SOAP-ENC:Array”>
<attribute ref=”SOAP-ENC:arrayType”
wsdl:arrayType=”string[]”/>
</restriction>
</complexContent>
</complexType>
</schema>
Figura 38 - Definição do array de objetos Assinante, e do array de Strings
Em WSDL, os parâmetros de entrada e saída de cada operação são definidos
como elemento <message>, desta forma, torna-se necessária a definição dos seguintes
elementos na operação getAssinantesList.
<message name=”GetAssinantesListRequest”>
<part name=”cidade” type=”xsd:string”/>
<part name=”ramoAtividade” type=”xsd:string”/>
</message>
<message name=”GetAssinantesListResponse”>
<part name=”assinantes” type=”s:ArrayOfAssinante”/>
</message>
Figura 39 - Definição dos elementos na operação getAssinantesList
Feita a definição dos elementos <message>, cada serviço precisa ser definido
como uma <operation>. Por exemplo, a operação getAssinantesList pode ser
definida usando o seguinte código WSDL:
<operation name=”getAssinantesList”>
<input message=”tns:GetAssinantesListRequest”/>
<output message=”tns:GetAssinantesListResponse”/>
</operation>
Figura 40 - Código WSDL da operação getAssinantesList
Em seguida, cada operação deverá ser colocada dentro do elemento <portType>,
como pode ser visto na codificação abaixo:
<portType name=”PhoneListServices”>
<input message=”tns:GetAssinantesListRequest”/>
<output message=”tns:GetAssinantesListResponse”/>
</operation>
<operation name=”getRamosAtividadesList”>
<input message=”tns:empty”/>
<output message=”tns:GetRamosAtividadesListResponse”/>
</operation>
<operation name=”getCidadesList”>
<input message=”tns:empty”/>
<output message=”tns:GetCidadesListResponse”/>
</operation>
</portType>
Figura 41 - Operações dentro do elemento <portType>
E por ultimo é necessário especificar, o protocolo
a ser utilizado para o
transporte das mensagens, o estilo do serviço e a codificação utilizada. Isto é feito
utilizando o elemento <binding>. Especificamente neste caso foram utilizados o
protocolo de transporte HTTP, o estilo RPC e a codificação SOAP.
O elemento <binding> precisa referenciar cada <operation> previamente
definida.
O fragmento de código abaixo, apresenta a operação getAssinantesList:
<binding name=”PhoneListServicesSOAPBinding”
type=”tns:PhoneListServices”>
<soap:binding style=”rpc”
transport=”http://schemas.xmlsoap.org/soap/http”/>
<soap:operation soapAction=””/>
<input>
<soap:body use=”encoded” namespace=”urn:phoneList”
encodingStyle=”http://schemas.xmlsoap.org/soap/encoding/”/>
</input>
<output>
<soap:body use=”encoded” namespace=”urn:phoneList”
encodingStyle=”http://schemas.xmlsoap.org/soap/encoding/”/>
</output>
</operation>
</binding>
Figura 42 - Operação getAssinantesList
Os códigos apresentados nas Figuras 37 a 42, escritos utilizando a linguagem
WSDL, contêm todas as informações necessárias a respeito das operações.
A fim de definir e especificar um Web Service a última especificação necessária é
a do elemento <service>, e para realizar tal serviço, é necessário a criação do elemento
<port> que usará os elementos <porType> e <binding> definidos anteriormente:
<service name=”PhoneListService”>
<port name=”PhoneListServices”
binding=”tns:PhoneListServicesSOAPBinding”>
<soap:addresslocation = “http://localhost:8080/axis/services/PhoneListServices”/>
</port>
</service>
Figura 43 - Especificação do elemento <service>
Da mesma forma, será necessária a criação do arquivo WSDL usado para
especificar o phoneProvider Web Service.
A criação do WSDL de cada Web Service é a questão chave do projeto,
desenvolvimento e implantação dos Web Services.
4.4.3 Geração dos Códigos dos Web Services
Nesta etapa devem ser geradas todas as classes Java necessárias à implementação
do serviço. Para realizar tal tarefa, foi utilizada uma ferramenta chamada WSDL2Java,
que vem junto com o Axis, e aplicada a todos os arquivos WSDL criados para os Web
Services.
A Figura 44 apresenta as classes automaticamente geradas, sendo que
PhoneListServicesSOAPBindingImpl
foi a única codificada manualmente, pois
contém os procedimentos do negocio. Esta classe sempre tem o nome do elemento
<binding> mais a string “Impl.Java”.
Figura 44 - Classes automaticamente geradas pela ferramenta WSDL2Java
As classes apresentadas na Figura 44 foram usadas para criar os arquivos do lado
do servidor, e correspondem às classes usadas para criar seu próprio serviço.
Para fazer uso do serviço é necessário obter a especificação WSDL do serviço
construído e, usar a ferramenta WSDL2Java para processar este arquivo e gerar os
arquivos do lado do cliente.
Neste estudo os arquivos são:
•
Assinante.Java;
•
PhoneListService.Java;
•
PhoneListServiceLocator;
•
PhoneListeServices;
•
PhoneListServicesSOAPBindingStub.
Neste caso foi necessário obter o WSDL phoneList para criar a classe cliente e
usá-la no Web Service phoneProvider. Estas classes permitiram ao
Web Service
phoneProvider utilizar o serviço phoneList.
4.4.4 Implantação dos Web Services
Após a codificação de cada operação feita pelos Web Services, a última tarefa a
ser feita antes de usá-lo é a implantação do serviço.
A
Figura
undeploy.wsdd,
44
mostra
dois
arquivos
chamados
deploy.wsdd
e
gerados pela ferramenta WSDL2Java. Ambos os arquivos são
basicamente um documento XML, que será usado pela ferramenta AdminClient [02],
para tornar o serviço disponível ou indisponível, ao ambiente AXIS. A ferramenta
processa o arquivo, e então o serviço está pronto para ser utilizado pelo cliente ou outros
Web Services.
A Figura 45 apresenta como o AXIS mostra as informações sobre o Web Service
phoneList após sua implantação (deploy).
Figura 45 - Web Service construído
Usando o mesmo método, após a criação do arquivo WSDL que especifica o Web
Service phoneProvider foi necessário gerar seu código, implementar seus serviços e
finalmente implantá-lo (deploy) no servidor do fornecedor.
4.4.5 Usando os Web Services
Para demonstrar o uso dos Web Services foi criada para o cliente, neste caso uma
suposta Agência de Turismo, uma aplicação em JAVA que usa o serviço do fornecedor
(phoneProvider).
Este cliente não tem conhecimento dos recursos utilizados por este fornecedor
para fornecer as informações desejadas por ele, ou seja, não sabe da existência de um
segundo Web Service (phoneList) envolvido nas operações. Para criar esta aplicação
foi necessário usar o arquivo phoneProvider e, então gerar os arquivos do cliente.
A Figura 46 apresenta a tela da aplicação usada pelo cliente, após uma consulta
que utilizou os Web Services phoneProvider e phoneList.
A consulta do cliente neste caso, não teve bairro informado e, somente a palavra
peixoto como rua. Tal consulta teve como resultado, uma lista de todos os assinantes da
cidade de Uberlândia, cujo Ramo de Atividade é Hotel, localizados em qualquer
bairro e, que tenham em seu nome de rua a String Peixoto.
Figura 46 - Aplicação Cliente
A cadeia de serviços proposta neste estudo de caso é uma solução para a
necessidade de um usuário, no caso uma Agência de Turismo. No entanto, este mesmo
fornecedor pode ter outros Web Sevices disponíveis que completarão os serviços
desejados pelo cliente, como por exemplo: reserva nos hotéis, nos restaurantes, nos
teatros, etc.
Portanto, esta cadeia de Web Services pode se expandir na medida em que as
necessidades forem surgindo, oferecendo serviços cada vez mais ricos na Web.
4.5 Avaliação
Segundo a WSA (Web Services Architecture), as principais metas arquiteturais de
um Serviço Web estão descritas no documento que contém os requisitos necessários à
arquitetura de uma WS, e são elas:
•
Interoperabilidade entre os Serviços Web;
•
Integração com a Internet;
•
Confiabilidade dos Serviços;
•
Segurança dos Serviços;
•
Gerenciamento dos Serviços.
Diante dessas propostas, pôde-se avaliar ao final deste trabalho que:
A Maturidade da Tecnologia – Se considerarmos que uma das unidades de
medida de maturidade de uma tecnologia é o número de sistemas desenvolvidos e em
desenvolvimento, então, WS ainda tem muito que caminhar para considerar-se uma
tecnologia amadurecida, pois muitas avaliações ainda deverão ser feitas,
principalmente no aspecto segurança, porém outros aspectos foram possíveis de
serem verificados como:
•
Interoperabilidade – Foi implantada e obtida com sucesso, já que dois
ambientes operacionais distintos foram utilizados sem dificuldade de
integração;
•
World Wide Web - O HTTP, protocolo utilizado como meio de transporte
para as mensagens SOAP, comportou-se de uma forma segura. E por tratar-se
de um protoloco que utiliza a porta 80, de acesso livre para a Internet, facilita
o desenvolvimento de aplicativos com estas características, ou seja, de
softwares que ficarão disponíveis para acesso externos;
•
Confiabilidade – Apesar par de existir ainda uma série de testes para serem
feitos, esta primeira versão da cadeia de Web Services não apresentou
problemas neste aspecto;
•
Segurança e Gerenciamento – Quanto a estes itens, não houve tempo
suficiente para uma avaliação apurada, porém com a continuidade deste
trabalho, testes elaborados serão realizados com intuito de uma melhor
verificação destes aspectos. Segundo as pesquisas feitas em relação a
gerenciamento e segurança de Web Services, ainda há muito que avançar e
amadurecer;
•
Facilidades x Dificuldades – As tecnologias aqui utilizadas para implantação
e uso dos WS (Java, Apache Axis, Tomcat) foram implantadas e utilizadas
sem nenhuma dificuldade, baseadas simplesmente nas orientações fornecidas
por seus fabricantes. Obviamente que para o uso destas ferramentas exige
experiência na área de informática.
Existem no mercado atualmente outras ferramentas para desenvolvimento e
implantação de Serviços Web como: Microsoft - Visual Studio.net; IBM - WSTK (Web
Services Tool Kit); ORACLE - Oracle9iAS e a Sun - SunOne (Sun Open Net
Environment), com as mesmas possibilidades de sucesso conseguidas com o Apache
Axis. Porém, como o objetivo deste estudo não era verificar as ferramentas disponíveis
no mercado, mas sim uma abordagem para desenvolvimento de serviços baseados em
WS, testes com outras implementações não foram realizados.
WS são componentes de software que podem ser invocados por outros componentes
através da Web, permitindo assim a troca de informações e a disponibilização,
independentemente de localização, sistema operacional ou linguagem de programação
utilizada. A tecnologia WS promete resolver uma questão que até o presente momento
tem sido complexa que é a interoperabilidade entre os componentes.
Apesar de tratar-se de uma tecnologia relativamente recente, como ela é apoiada por
verdadeiros gigantes como a IBM, ORACLE, Sun, HP, BEA, Microsoft e outros, isto
leva a crer que não se trata de mais um modismo, mas sim de uma nova tendência.
Outra avaliação interessante a ser considerada é a procura por serviços na Internet. O
crescimento exponencial das informações na Web e a dificuldade para indexá-las com a
linguagem HTML, causa muitas vezes certas decepções. Por exemplo: uma pesquisa
com a palavra “SAUDE” provavelmente retornará um considerável número de respostas
que não interessará ao usuário.
Cabe então a este usuário a tarefa de identificar as diferenças e escolher a resposta
que lhe convém. O problema é que esta diferença só é entendida pelos humanos e não
fazem diferença para os programas de computador que ainda estão distante de imitar o
funcionamento do cérebro humano e resolver estas ambigüidades.
Um novo conceito de Web começa a surgir no mercado como uma tentativa de
resolver esta questão. Trata-se da Web Semântica (Semantic Web) [31], onde a idéia é
que as informações sejam também entendidas pela máquina e não só pelo ser humano,
ou seja, informação compreensível pela máquina ou Machine-understandable
Information, segundo o pai da Web, Tim Berners-lee .
Neste contexto a linguagem XML é o componente central que permite descrever os
dados de uma forma semântica, a partir das categorias determinadas pelo próprio
usuário.
Outras tecnologias e conceitos, no entanto, precisam ser associados ao XML para o
sucesso da Web Semântica, como: URI (Universal Resource Identifier) como a
URL[34]; RDF (Resource Description Framework) que é uma linguagem e uma
gramática para definir informações na Web [34]; Ontologias [34 ] que são conjuntos de
afirmações os quais definem as relações entre conceitos e estabelecem regras lógicas de
raciocínio sobre eles; Agentes, que são softwares que funcionam sem o controle direto
ou supervisão para executarem suas tarefas [32].
Portanto, a idéia central da Web Semântica é buscar através de seu agente, as
informações realmente relevantes, o que torna um recurso fundamental para o sucesso
dos Web Services e também a semântica da troca de mensagens entre o provedor e o
requisitante.
É inegável que os WS produzirão uma grande transformação na Internet, pois
com eles torna-se possível que um grande volume de transações entre empresas aconteça
com grande velocidade e facilidade. Se pensarmos em transações entre empresas com
ambientes heterogêneos, plataformas diferentes que podem responder às solicitações em
tempos variados, como teremos a garantia, por exemplo, que um serviço solicitado a
uma empresa localizada no exterior, responderá com a rapidez necessária.
Outro agravante é que os sistemas atuais são constantemente atualizados com
novas versões. Para isto existem ferramentas para EAI (Enterprise Apllication
Integration) [35] que devem ser utilizadas para orquestrar os Web Services. Deste modo
pode-se ter todo o fluxo de uma operação B2B visualizado graficamente, e as alterações,
quando necessárias, realizadas na interface gráfica.
Se pensarmos que as interações entre processos remotos envolvem muitas vezes
transações complexas que necessitam de alta disponibilidade e escalabilidade é
fundamental o uso da orquestração dos WS para que os negócios entre empresas sejam
executados de uma forma segura e rápida.
A Figura 47 apresenta um quadro comparativo entre as tecnologias discutidas
neste relatório.
WS
RPC
ORB
J2EE
.NET
Gerenciamento
N/D
N/D
Interoperabilidade
Ótima
Regular
Fraca
Regular
Fraca
Segurança
Fraca
Fraca
Boa
Ótima
Boa
Integração de
Ótima
Regular
Boa
Ótima
Ótima
Ótima
Fraca
Fraca
Regular Regular Regular
Sistema
Manutenção
Regular Regular
Figura 47 - Quadro Comparativo
5. Conclusões e Trabalhos Futuros
No mundo dos negócios, as empresas sempre tiveram a necessidade de manter um
relacionamento intenso, a fim de garantir sua sobrevivência no mercado competitivo.
Com o passar dos tempos e avanço das tecnologias de comunicação, esta forma de
relacionamento sofre consideráveis mudanças de comportamento e necessidades.
Esta constante e rápida evolução nos meios de comunicação tem provocado saltos
consideráveis na maneira como as empresas realizam suas transações com fornecedores
e clientes, que cada vez mais exigem qualidade, agilidade e segurança nos serviços
prestados.
Entre as mais diversas formas de integração entre as empresas, a informática tem
apresentado enormes contribuições, pois representa uma fundamental ferramenta para a
implementação e sucesso destas evoluções.
O fato das empresas sempre buscarem qualidade e rapidez na prestação de
serviços, muitas vezes provocam o avanço das tecnologias, principalmente para troca
de informações e dados e hoje, é impensável uma empresa de negócios que não faça uso
da Internet, ferramenta importante para o sucesso dos negócios, e aquelas que não a
usam correm o risco de ficar fora do mercado. Sendo assim, este trabalho conclui que
Web Services ou uma cadeia de Web Services:
•
Usando os conceitos HTTP, SOAP e XML juntamente com o WSDL é possível
desenvolver e implantar o conceito de Serviços Web;
•
Apresenta-se como uma nova maneira de integração entre aplicações com
característica heterogêneas (interoperabiliade);
•
Funciona de uma forma totalmente transparente para seus usuários;
•
Apresentou a viabilidade de utilização de WS na implementação de aplicações
B2B (Business to Business);
•
A possibilidade de divulgação de seu serviço de uma forma padronizada em um
meio tão poderoso quanto a Internet, permite enormes chances de atingir um
público bem maior de interessados;
•
A possibilidade de sistemas totalmente heterogêneos serem suficientemente
independentes para agirem por conta própria, e se comunicarem quando
necessário, independentemente de plataformas, sistemas operacionais e
linguagens de programação, gera novas facilidades de integração com sistemas
atuais e legados;
•
Um grupo de Web Services, implantado em diferentes companhias, pode gerar
uma cadeia de serviços, usando enlaces de alta velocidade para se conectarem.
Neste ambiente, apesar de ser transparente para o cliente, ele poderá contar com
resultados mais rápidos;
•
O desenvolvimento e implantação de um ambiente para Web Services, exige de
seu analista um conhecimento de várias tecnologias, como por exemplo: projeto
de sistemas, linguagens de programação, sistemas operacionais, plataformas de
desenvolvimentos, e outros.
A partir das potencialidades de Web Services apresentadas neste trabalho, pode-se
vislumbrar os seguintes trabalhos futuros:
•
Implantar outras cadeias de serviços utilizando ferramentas diferentes existentes
no mercado como as da IBM, MICROSOFT, SUN e ORACLE;
•
A possibilidade de aplicação comunicando com aplicação em empresas
diferentes, gera uma nova preocupação para os fornecedores de serviços, a
segurança. Há muito trabalho a ser feito nesta área, ou seja, o desenvolvimento
de procedimentos de segurança como: assinaturas digitais, certificados digitais,
criptografias, etc..Empresas fornecedoras de software, tem investido fortemente
nesta área;
•
J2EE e .Net são arquiteturas oferecidas por diferentes fornecedores, sem
nenhuma preocupação com interoperabilidade. A tecnologia dos Web Services é
uma candidata natural para integrar estas arquiteturas;
•
Através do uso do WSDL, é possível automatizar o código do cliente e o do
servidor. Isto aumenta a interoperabilidade e abre um excelente caminho para
absorver uma enorme quantidade de diferentes funcionalidades que, dia a dia,
aparecem no mercado.
6. Referência Bibliográfica
[01] Axis User's Guide. Apache Software Foundation.
Disponível em : < http://ws.apache.org/axis/java/user-guide.html >
Acessado em: 07 de outubro de 2003.
[02] Axis installation instructions. Apache Software Foundation.
Disponível em: < http://ws.apache.org/axis/java/install.html >
Acessado em 27 de outubro de 2003.
[03] The Apache Jakarta Project. Apache Software Foundation.
Disponível em: <http://jakarta.apache.org/tomcat/index.html>.
[04] The Apache Ant Project. Axis-wsdl2java Task.
Apache Software Foundation.
Disponível em: < http://ws.apache.org/axis/java/ant/axis-wsdl2java.html >.
[05] Schimidt´s, Douglas c.; Overview of CORBA
Disponível em: http://www.cs.wustl.edu/~schmidt/corba.html
Acessado em: 07 de agosto de 2003
[06] TANENBAUM, Andrew S.; Sistemas Operacionais Modernos", Editora
1999.
[07] LIMA, Rayfram Rocha. Tutorial Corba.
LTC,
Disponível em: <http://www.mundooo.com.br/php>.
Acessado em: 11 de setembro de 2003
[08] C. Montez; Um modelo de Programação para Aplicações de Tempo real em
Sistemas Abertos., Monografiado Exame de Qualificação de Doutorado,
DAS, UFSC, julho de 1987.
Disponível em < http://www.lemi.ufsc/~montez/corba/corba.html >.
Acessado em 09 de setembro de 2003.
[09] HORSTMANN, Markus; KIRTLAND, Mary. DCOM Architecture.
Disponível em:
<http://www.msdn.microsoft.com/library/en-us/dndcom/html/ >.
Acessado em: 04 de setembro de 2003
[10] W3C; HyperText Markup Language; Home Page.
Disponível em < http://www.w3.org/MarkUp/ >
Acessado em 20 de junho de 2003.
[11] PAWLAN, Monica; The J2EE Tutorial.
Disponível em: <http://java.sun.com/j2ee/tutorial/1_3-fcs/doc/Overview.html>
Acessado em 27 de setembro de 2003.
[12] Oliveira, Alcione de Paiva; Maciel, Vinícius Valente;
Java na Prática, (Volumes I e II); Universidade Federal de Viçosa;
Departamento de Informática.
[13] W3C; Overview of SGML Resources
Disponível em: < http://www.w3.org/MarkUp/SGML/ >
Acessado em:20 de junho de 2003.
[14] Box, D. et al. Simple Object Access Protocol (SOAP) 1.1.
World Wide Web Consortium Note, 2000.
Disponível em: <http://www.w3.org/TR/2000/NOTE-SOAP-20000508>.
Acessado em: 15 de agosto de 2003
[15] Harold, E. R. Processing XML with Java: A Guide to SAX, DOM, JDOM,
JAXP, and TrAX. Boston, MA: Addison Wesley, 2002. 1120 p.
[16] BRAY, Tim; PAOLI, Jean, SPERBERG, C. M., MALER, Eve.
Extensible Markup Language (XML) 1.0 (Second Edition).
Disponível em <http://www.w3.org/TR/2000/REC-xml-20001006 >.
Acessado em 15 de agosto de 2003.
[17] Centro de Competência de Software em XML.Curitiba – PR.
Histórico da Tecnologia XML
Disponível em http://www.institutoxml.org.br/historico.aspx.
Acessado em 04/09/2003.
[18] CHAMPION, et al. Web Services Architecture – W3C Working Draft 14 November
2002.
Disponível em < http://www.w3.org/tr/2002/WD-ws- arch- 20021114/ >
Acessado em 25/04/2003.
[19] Marcio Boaro; Web Services – Uma Visão Inicial;
Disponível em: http://www.csit.com.br/html/artigos/artigo08.htm
Acessado em : 20 de marco de 2003
[20] Chinnici, Roberto et al. Web Services Description Language (WSDL)
Version 1.2 Part 1: Core LanguageW3C Working Draft 11 June 2003.
Disponível em: http://www.w3.org/TR/2003/WD-wsdl12-20030611/
Acessado em: - 15 de agosto de 2003.
[21] Christensen, E. et al. (2001) Web Services Description Language (WSDL) 1.1.
World Wide Web Consortium Note.
Disponível em <http://www.w3.org/TR/wsdl>.
Acessado em: 27 de novembro de 2003.
[22] Timothy Appnel; An Introduction to WSIL (Web Service Inspection language);
Disponível em: http://www.oreillynet.com/pub/a/onjava/2002/10/16/wsil.html
Acessado em 21 de marco de 2003.
[23] Douglas Bryan et al; UDDI Version 2.04 API Specification;
Disponível em: <http://uddi.org/pubs/ProgrammersAPI-V2.04-Published-20020719.htm>
Acessado em : 20 de abril de 2003
[24] Henry, Kevin; Distributed Computation with Java Remote Method Invocation
Disponível em: < http://www.acm.org/crossroads/xrds6-5/ovp65.html >
Acessado em: 20 de abril de 2003
[25] Luís Pereira, João Carmo; Mecanismos de Geração de Código na plataforma .Net
Disponível em: < http://mega.rnl.ist.utl.pt/~ic-micro/ uP_01_02_artigo_sintese_1.pdf >
Acessado em: 23/09/2003
[26] Microsoft .Net; What is .NET
Disponível em < http://www.microsoft.com/net/basics/ >
Acessado em 15 de junho de 2003.
[27] Object Management Group, Inc.; Introduction to OMG's Unified Modeling
Language;
Disponível em: < http://www.omg.org/oma/ >
Acessado em 20 de junho de 2003
[28] Object Management Group, Inc.; Introduction to OMG's Unified Modeling
Language;
Disponível em: < http://www.omg.org/uml/ >
Acessado em 20 de junho de 2003
[29] Bowman, Phil et al ; Remote Procedure Call
Disponível em:
http://searchwebservices.techtarget.com/sDefinition/0,,sid26_gci214272,00.html
Acessado em : 12/04/2003
[30] Sun Microsystems; JAVA IDL;
Disponível em: http://java.sun.com/j2se/1.3/docs/guide/idl/;
Acessado em; 20/06/2003
[31] W3C Semantic Web Activity Statement
Disponível em: http://www.w3.org/2001/sw/Activity/;
[32] Berners-Lee, Tim; Semantic Web Road map
Disponível em: http://www.w3.org/DesingnIssues/Semantic/;
[33] Booth, D. et al. Web Services Architecture. World Wide Web Consortium Working
Draft, 2003.
Disponível em <http://www.w3.org/TR/2003/WD-ws-arch-20030808>.
Acessado em: 27 de novembro de 2003.
[34] O futuro da Internet
Disponível em <http://www.comciencia.br>.
Acessado em: 12 janeiro de 2004.
[35] Garcia, Simone de Souza, et al; EAI – Enterprise Apllication Integration
Núcleo de Computação Eletrônica – Universidade Federal do Rio de Janeiro.

João Augusto Alves Pacheco - Universidade Federal de Uberlândia

Transcrição

Documentos relacionados

da monografia

Aula – Web Services - Carlos Eduardo Dantas

Baixe o descritivo do curso

teorico

Com a aquisição da empresa KL Services, o grupo STEF consolida

Seresco é a anfitriã da cimeira anual que reúne os

Baixe o descritivo do curso

Sistemas Distribuídos – LEIC, LERC

SA 8000:2008 - Personal Service

OHSAS 18001:2007 - Personal Service