1
World Wid e We b
Mário Meireles TeixeiraDepartamento de Informática, [email protected]
2
Vis ã o Ge ra l d a In t e rn e t
� Internet � Uma rede formada por diversas redes (internetwork).
� É um conjunto de LANs/WANs interligadas a fim de fornecer facilidades de comunicação comuns. As tecnologias e protocolos de cada rede individual tornam-se transparentes aos usuários.
� Necessidades:� Um protocolo comum� Administração de Nomes� Segurança...
3
Os Pro toco los da In t e rn e t
� Em termos lógicos, a comunicação na Internet se baseia na família de protocolos TCP/IP.
� Os protocolos TCP/IP foram criados pelo Dept. de Defesa dos EUA, tendo sido adotados como padrão no UNIX a partir do 4.3 BSD.
� Protocolos:� TCP, UDP, IP, ARP, RARP, ICMP, RIP, SMTP, HTTP, DNS, SLIP,
PPP...
4
Pro toco los TCP/IP
� Os protocolos da família TCP/IP constituem a base para a interligação dos computadores na Internet
� Arquitetura dividida em camadas:� Aplicação, Transporte, Internet e Acesso à Rede
� IP � Protocolo de Roteamento
� TCP, UDP � Protocolos de Transporte
� FTP, TELNET, DNS, SMTP, SNMP, NFS, HTTP ... � Protocolos da Camada de Aplicação
HTTP
5
Ca m a d a s TCP/IP
IP3 Internet
TCP UDP4 Transporte
HTTP5 Aplicação
(diferentes protocolos)1, 2 Acesso à rede
6
A World Wid e We b
� Conceito: Estrutura arquitetônica que permite o acesso a documentos interligados espalhados pela Internet.
� Aplicação tão popular que muitas pessoas pensam ser �A Internet�, porém é a aplicação do hipertexto na Internet.
� Utilizações: � Biblioteca: publicação e compartilhamento de
informações.� Comercial: Divulgação de produtos e realização de
transações comerciais.� Educação, comunicação, etc.
7
Evolu çã o d o Hip e rt e xto e d a We b
� Em 1945, Vannevar Bush introduziu o conceito de hipertexto: modelo que organiza o conhecimento num grafo onde vértices são recursos e arestas são referências cruzadas, porém os termos foram utilizados apenas em 1965 por Ted Nelson.
� A Web teve início em 1989, no centro de pesquisa CERN, surgindo da necessidade de compartilhamento de informações. Nesse ano, Tim Berners-Lee criou o protocolo HTTP
8
Evolu çã o d o Hip e rt e xto e d a We b
� Berners-Lee apresentou uma proposta para o gerencia-mento das informações do CERN e o primeiro protótipo tornou-se operacional já em 1991.
� A pesquisa avançou e Marc Andreessen desenvolveu o primeiro navegador gráfico, o Mosaic, que popularizou o uso da Web.
� Chegou-se, finalmente, à solução atual: o hipertexto, com a possibilidade dos links poderem conter elementos multimídia
� Em 1994, foi criado o W3C (World Wide Web Consortium), voltado para o desenvolvimento Web, padronização de protocolos e incentivo à interoperabilidade de sites.
9
Org a n iza çã o d a We b
� Em 1995, a Web tornou-se responsável pela maior parte do tráfego na Internet. Mas em 2002 foi superada pelas redes P2P
� A Web é um gigantesco sistema de hipertexto em escala global� Separação entre o software de armazenamento da informação e
o software de visualização da mesma� Sistema de nomenclatura � URLs� Interações entre os componentes � Paradigma C/S
� A Web funciona sobre dois padrões:� Linguagem HTML� Protocolo HTTP
Independência de plataforma
10
Sis te m a d e Nom e n cla tu ra � URLs
� URLs permitem que os usuários acessem páginas web e outros serviços como FTP, telnet, notícias, utilizando como interface o próprio navegador:� http - Hipertexto (HTML)� ftp - Transferência de arquivos� file - Acesso a arquivos locais� news - Grupos de notícias e artigos� gopher - recuperar informações pelo gopher� mailto - Enviar e-mail� telnet - Login remoto
11
Pro toco lo HTTP
HTTP: hypertext transfer protocol
� protocolo da camada de aplicação da Web
� modelo cliente/servidor� cliente: browser que
solicita, recebe e apresenta objetos da Web
� server: envia objetos em resposta a pedidos
� HTTP 1.0: RFC 1945� HTTP 1.1: RFC 2616
PC comExplorer
Servidorcom
Apacheweb server
Mac comNavigator
http request
http re
quest
http response
http re
sponse
12
Pro tocolo HTTP
http: protocolo de aplicação sobre TCP
� cliente inicia conexão TCP (cria socket) com o servidor na porta 80
� servidor aceita uma conexão TCP do cliente
� mensagens http são trocadas entre o browser (cliente http) e o servidor web (servidor http)
� A conexão TCP é fechada
http é �stateless�:� o servidor não mantém
informações sobre os pedidos dos clientes
Protocolos que mantêm informações de estado são complexos:
� necessidade de organizar infor-mações passadas
� se ocorrer uma falha, as infor-mações podem ser perdidas ou gerar inconsistências entre o cliente e o servidor
� baixa escalabilidade
13
Exe m p lo d e Op e ra çã o HTTP (1 )Usuário digita a URL: www.deinf.ufma.br/prof/index.html
1a. cliente http inicia conexão TCP com o servidor http (processo) em www.deinf.
ufma.br, pela porta 80 (default)
2. cliente http client envia http request, contendo a URL, ao servidor web
1b. servidor http no host www.deinf.ufma.br, aguardando pela conexão TCP na porta 80, aceita a conexão, notificando o cliente
3. servidor http recebe mensagem de pedido, recupera o objeto e envia uma http response, contendo o objeto solicitado, ao cliente
tempo
(referencia 10 imagens)
14
Exe m p lo (2 )
5. cliente http recebe mensagem de resposta contendo o arquivo html e o apresenta ao usuário
5a. ao analisar o arquivo html, cliente encontra 10 objetos jpeg referenciados
6. cliente repete Passos 1-5 para cada um dos 10 objetos jpeg
4. servidor http fecha conexão TCP (http 1.0)
tempo
15
Con e xõe s p e rs is t e n te s e n ã o-
p e rs is t e n te s
Não-persistente� http/1.0: servidor analisa
pedido, envia resposta e fecha a conexão TCP
� 2 RTTs para obter um objeto:� estabelecimento de
conexão TCP� solicitação e transferência
do objeto� cada transferência sofre ainda
por causa do mecanismo de slow-start do TCP
� muitos browsers abrem várias conexões paralelas
Persistente� modo default para http/1.1
� na mesma conexão TCP, são recuperados vários objetos
� o cliente solicita todos os objetos referenciados, tão logo ele receba a página HTML básica (pipelining)
� poucos RTTs, menos slow start
16
HTTP re q u e s t : form a to g e ra l
<método> <id. recurso> <versão HTTP> <crlf>[<Header>: <valor>] <crlf> . . . [<Header>: <valor>] <crlf><crlf>[Entity body]
17
Me n s a g e n s HTTP: re q u e s t
� Dois tipos de mensagens HTTP: request, response� Formato ASCII (legível para humanos)
GET /dir/page.html HTTP/1.0
User-agent: Mozilla/4.0
Accept: text/html, image/gif, image/
jpeg
Accept-language: fr
(linha em branco)
Corpo da mensagem
linha de pedido(comandos GET,POST,HEAD )
linhas decabeçalho
Carriage return, line feed
indica fim da mensagem
18
HTTP re s p on s e : form a to g e ra l
<versão HTTP> <cód. status> [<explicação>] <crlf>[<Header>: <valor>] <crlf> . . .[<Header>: <valor>] <crlf><crlf>[Entity body]
19
Me n s a g e n s HTTP:
re s p on s e
HTTP/1.0 200 OK
Date: Thu, 06 Aug 1998 12:00:15 GMT
Server: Apache/1.3.0 (Unix)
Last-Modified: Mon, 22 Jun 1998 ...
Content-Length: 6821
Content-Type: text/html
dados dados dados dados ...
linha de status(protocolo
código de status frase de status)
linhas decabeçalho
dados, p.ex., arquivo html
20
Mé todos HTTP
� GET � Solicita o objeto identificado pela URL� HEAD � Obtém informações sobre o objeto sem que o
mesmo seja retornado ao cliente (depuração)� POST � Envia informações adicionais ao servidor web
(p.ex., dados de formulários)� OPTIONS � Obtém opções de comunicação disponíveis ou
os requisitos associados ao objeto solicitado� PUT � Cria ou modifica um objeto no servidor web� DELETE � Remove um objeto do servidor web� TRACE � Envia mensagem de teste (loopback) ao servidor� CONNECT � Reservado para comunicação com servidores
proxy
21
Cód ig os d e Sta tu s
� 1xx � Informational
� 2xx � Success� 200 OK
� 3xx � Redirection� 301 Moved Permanently� 304 Not Modified� 307 Temporary Redirect
� 4xx � Client Error� 400 Bad Request� 401 Unauthorized� 404 Not Found
� 5xx � Server Error� 503 Service Unavailable� 505 HTTP Version Not
Supported
22
Cookie s
� Gerados e lembrados pelo servidor (RFC 2109), usados mais tarde para:� autenticação� lembrar preferências dos
usuários ou escolhas prévias
� Servidor envia �cookie� ao cliente na resposta HTTPSet-cookie: 1678453
� Cliente apresenta �cookie� em pedidos posterioresCookie: 1678453
cliente servidor
http request msg
http response +Set-cookie: #
http request msgCookie: #
http response msg
http request msgCookie: #
usual http response msg
açãoespecíficado cookie
açãoespecífica do cookie
açãoespecíficado cookie
23
GET Cond ic ion a l: ca ch e s n o
clie n te
� servidor: só envia o objeto solicitado se sua versão for mais atual que a do cliente
� cliente: especifica, na requi-sição HTTP, a data da versão armazenada no cache local:If-Modified-Since:
<date>
� servidor: resposta não contém o objeto se a cópia do cliente estiver atualizada: 304 Not Modified
cliente servidor
http requestIf-Modified-Since:
<date>
http responseHTTP/1.0
304 Not Modified
objeto não
modificado
http requestIf-Modified-Since:
<date>
http responseHTTP/1.1 200 OK
<data>
objeto modificado
24
We b Ca ch e s
� usuário configura o browser: � acesso à Web é feito através
de um servidor proxy� cliente envia todos os
pedidos http para o proxy:� se o objeto existe no cache,
o proxy retorna o objeto� senão, o proxy solicita o
objeto ao servidor original e o envia ao cliente
Objetivo: atender o cliente sem envolver o servidor Web, detentor da informação original
cliente
Proxyserver
cliente
http request
http re
quest
http response
http re
sponse
http request
http response
servidororiginal
25
Por q u e We b Ca ch ing ?
� armazenamento fica �perto� do cliente (p.ex., na mesma rede)
� menor tempo de resposta� reduz o tráfego para
servidores distantes:� links externos podem ser
caros e facilmente congestionáveis
� caches hierárquicos e cooperativos (NLANR)
� ICP (RFC 2186)� Internet Caching Protocol,
suportado pelo Squid
servidoresoriginais
Internetpública
redeinstitucional 10 Mbps LAN
enlace de acesso1,5 Mbps
cache institucional
26
Pa ra d ig m a Clie n te -
Se rvid or n a We b
27
A Evolu çã o d a We b
� Na evolução da Web, é possível observar quatro fases, sob o ponto de vista das aplicações:
� A Web como um repositório de documentos hipertexto� Mosaic
� A Web como um servidor de aplicação simples� CGI, ASP, PHP, HTML Dinâmico
� A Web como um meio de acesso a objetos servidores� CORBA/IIOP, XML, DOM
� A Web como um meio de acesso a serviços� SOAP, XML, WSDL, UDDI
28
Fa s e I - A Era d o Hip e rt e xto (ou a cria çã o d o m u n d o)
� Mosaic Browser (1993)� Aplicação C/S usando a Internet� C/S em duas camadas� Clientes magros, portáteis e �universais�� Servidores gordos� Independência de plataforma� A Web se constituía em:
� um Servidor de Documentos HTML; ou� um Servidor de Arquivos baseado em URLs.
30
Evolu çã o d a s Te cn olog ia sFa s e I
31
Fa s e II - A Era In t e ra t iva (CGI & Cia .)
� CGI - Common Gateway Interface (1995)� Permite executar aplicações no lado servidor� Parâmetros de entrada e resultados em HTML
� Independência de plataforma� Com o CGI, os browsers se tornaram os �terminais burros� de
antigamente� C/S em três camadas� Porém...
� O CGI é um protocolo stateless, lento e �antigo�
33
Alte rn a t iva s a o CGI
� CGI lança um novo processo para cada requisição que chega dos clientes � sobrecarga no servidor
� Soluções proprietárias visando melhor desempenho e interatividade:� No lado servidor:
� PHP, ASP, Java Servlets, JSP, .NET
� No lado cliente:� HTML Dinâmico, JavaScript, CSS
34
Evolu çã o d a s Te cn olog ia sFa s e II-a
35
Evolu çã o d a s Te cn olog ia sFa s e II-b
36
Fa s e III - A Era d os Ob je tos
Dis t rib u íd os (Ob je ct We b )
�Web technology and distributed object technology are naturally complementary. We want to ensure that OMG
and W3C work together to define a common future.�
Tim Berners-Lee
Diretor, W3C
38
Ob je tos Dis t rib u íd os n a We b
� O uso de CORBA/Java na Web traz os seguintes benefícios:� Acaba o gargalo do CGI no servidor� Propicia interações C/S não necessariamente baseadas em
HTML (parâmetros tipados)� CORBA guarda o estado dos clientes entre as invocações de
métodos� Balanceamento de carga no servidor (Adaptador de Objetos,
transações distribuídas)� Novas formas de interação/cooperação entre os servidores
39
Ob je tos Dis t rib u íd os n a We b
� Java - Transparência de Implementação (portabilidade)
CORBA - Transparência de Rede
� Existem vários esforços no sentido de integrar Java e CORBA:� Um ORB CORBA já faz parte do Java 2 (Java IDL)� Java RMI executa sobre CORBA/IIOP� Enterprise Java Beans (EJB) usa CORBA como seu modelo de
objetos distribuídos
41
Ob je tos Dis t rib u íd os n a We b
� Em resumo:� Java permite a criação de aplicações que podem executar
em qualquer máquina. Ideal para a confecção de pequenos clientes �portáteis�.
� CORBA viabiliza a criação de uma infra-estrutura de objetos distribuídos sobre a Internet.
� Concluindo, nesta nova visão:� HTTP é ideal para recuperar documentos HTML repletos de
componentes (Java Beans) ou applets.� Uma vez no cliente, estes usam um ORB para se comunicar
com os objetos no servidor.
42
O Pa ra d ig m a C/S n a Ob je ct We b
� Camada 1
� Executa em browsers web ou similares� Novas formas de interação: drag-and-drop, crítica de dados de
entrada no cliente, páginas �animadas�, ...� Presença de componentes (beans) no cliente� Interações C/C, C/S, S/C (callbacks)� HTTP é usado para o download das páginas� CORBA é usado para a comunicação C/S
43
O Pa ra d ig m a C/S n a Ob je ct We b
� Camada 2
� Executa em qualquer servidor que dê suporte a clientes HTTP e CORBA (UNIX�s, NT, NetWare, OS/2, Mac OS, OS/400, MVS, ... ).
� Os objetos CORBA se constituem na camada intermediária deste modelo C/S
� Interações entre objetos no servidor� Suporte a transações distribuídas é fundamental� Comunicação com a terceira camada via ORB (de preferência)
ou outros protocolos.
44
O Pa ra d ig m a C/S n a Ob je ct We b
� Camada 3
� Aqui ficam todos os recursos que estão à disposição dos clientes, acessados via objetos CORBA.
� Por exemplo: e-mail, news, BDRs, BDOOs, aplicações de mainframe, sistemas ERP, SAP, CSCW, EAD, E-commerce, . . .
46
Prin c ip a is Em p re s a s n a Ob je c t
We b� Netscape/AOL
� Coloca um ORB Java Visibroker em cada browser� Usa CORBA para a comunicação no Netscape Enterprise Server
� Oracle� Adotou CORBA/Java como a plataforma para sua NCA (Network
Computing Architecture)� Oracle 8i : toda a comunicação via ORB (Visibroker)� O engine de banco de dados está sendo subdividido em
componentes usando CORBA� Oracle Application Server 4.0
47
Prin c ip a is Em p re s a s n a Ob je c t
We b
� Sun/JavaSoft� CORBA está sendo integrado ao núcleo de Java� Sun adotou o Visibroker como seu ORB para o Solaris
� IBM/Lotus� Está baseando sua plataforma de computação distribuída
em CORBA� Java VMs em todos os seus SO�s� IBM WebSphere, Domino 5.0, Visual Age
� Outros� HP, Iona, Visigenic/Borland, Novell, GemStone, ODI,
Versant, Sybase, Symantec, Expersoft
48
Fa s e IV - A Era d os Se rviços We b(We b Se rvice s )
� Web Service� É uma aplicação, identificada por uma URI, cujas interfaces
podem ser definidas, descritas e descobertas como artefatos XML. As interações de um Web Service com outras aplicações usam mensagens baseadas em XML, trocadas por meio de protocolos baseados na Internet (W3C)
� Requisitos (padrões)� Comunicação � SOAP (Simple Object Access Protocol) sobre HTTP� Descrição de tipos � XML Schema� Descrição das interfaces dos serviços � WSDL (Web Services
Description Language)� Descoberta dos serviços � UDDI (Universal Description, Discovery
and Integration)
49
A Era d os Se rviços We b
� O �mantra� dos Web Services concentra-se em:� Interoperabilidade� Independência de plataforma� Conformidade total com os padrões do W3C (World Wide Web
Consortium)
� Empresas:� Sun Microsystems � J2EE/Glassfish� Microsoft � .NET� IBM� Apache � Axis/TomCat
50
In t e ra çã o C/S b a s e a d a e m We b
Se rvice s