1

World Wid e We b

Mário Meireles TeixeiraDepartamento de Informática, UFMAmario@deinf.ufma.br

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