1 Introdução

Os termos interoperabilidade e interconectividade são bastante usados

hoje em dia, e muitos ainda apontam que estas duas palavras serão essenciais
no que se refere a computação dos anos 90, mas por quê?

A interconectividade refere-se a ligação física a ser estabelecida entre

as partes que necessitam efetuar a comunicação, ou melhor, preocupa-se com
as características físicas, elétricas e mecânicas envolvidas neste processo de
interligação.

Já o termo interoperabilidade, aponta para a capacidade de haver

troca de informações entre as aplicações que estão sendo processadas nos
computadores, e que estas informações possam ser utilizadas para se atingir
objetivos comuns, como o trabalho cooperativo, integridade, segurança dos
dados e independência de equipamentos.

Para se usufruir a interconectividade e interoperabilidade torna-se

necessário a adoção de padrões, coisas estas que até anteriormente não
existiam, prova disso é que os fabricantes de hardware e desenvolvedores de
software desenvolveram cada um o seu próprio conjunto de regras.

É em meio a este cenário que surge a necessidade de interligação de

hardware e interoperação entre software. E é por isso que os termos
interconectividade e interoperabilidade serão palavras chaves nos anos 90,
pois existe uma real necessidade de interligar todo este aparato tecnológico
existente e fazer com que seja realmente produtivo.

Com esta visão, os fabricantes e desenvolvedores já procuram trabalhar

seguindo padrões sugeridos por órgãos internacionais como ISO, IEEE entre
outros, atingindo assim, neste momento, um certo grau de interoperabilidade e
interconectividade.

É claro que a interoperabilidade total está muito distante de ser

conseguida. Para se atingir isto haveria a necessidade de que todos os
fabricantes e desenvolvedores adotassem um mesmo padrão para seu
hardware e software, ou então desenvolver algum produto que consiga
comunicar-se com todos os padrões existentes.
2 Arquiteturas de redes

Uma grande variedade de arquiteturas de redes podem ser encontradas

no mercado atualmente, e esta variedade acaba por tornar a interoperabilidade
entre as aplicações mais difícil, visto que existem dificuldades no
relacionamento entre elas.

Este estudo faz um levantamento de algumas das arquiteturas mais

populares, buscando levantar os pontos comuns entre as mesmas, a fim de se
obter subsídios para se atingir a interoperabilidade e interconectividade.

2.1 O modelo OSI - Open System Interconnection

Em 1977, o comitê técnico 97 da ISO (International Organization for

Standardization), reconheceu a necessidade de padrões para redes de
informações heterogêneas, e decidiu criar um novo subcomitê (SC16) para
estudar este problema e apresentar soluções para a interconexão dos mesmos
([TARO86], [ZIMM80], [REAR88] e [FOLT82]).

No final do estudo, chegou-se a um modelo denominado OSI (Open

Systems Interconnection), que deveria garantir uma estrutura para a definição,
desenvolvimento e validação de padrões na nova geração de sistemas de
informações distribuídas. O trabalho foi direcionado para definir a
funcionalidade necessária à comunicação entre processos de aplicações
localizadas remotamente em diferentes sistemas heterogêneos [FOLT82].

O propósito deste modelo de referência é propor base comum para a

coordenação da padronização do desenvolvimento de todo e qualquer produto
para a interconexão de sistemas de informação sem interferir no funcionamento
interno do sistema individual [ALVE92]. Tarouco [TARO86] também apresenta
que o modelo de referência OSI foi criado com vistas a servir de base para a
definição de projetos de padronização da interconexão de sistemas abertos. A
interconexão de sistemas abertos implica na conexão, por algum meio, de
sistemas compreendendo computadores, seus periféricos, terminais,
operadores humanos e processos físicos.

O termo sistema deve ser entendido, como sendo um conjunto de um

ou mais computadores, o software associado, seus periféricos, terminais,
operadores humanos, processos físicos, meios de transferência de informação
etc, que formam um todo capaz de executar processamento e/ou transferência
de informação.

Já o termo aberto (open), foi escolhido para enfatizar o fato de que, de

acordo com os padrões internacionais, um sistema deveria ser aberto para
todos os outros sistemas, obedecendo os mesmos padrões estabelecidos pelo
mundo. Já Folts [FOLT82], apresenta que o termo aberto é usado para
assegurar a habilidade de um sistema de um fabricante (ou projeto),
interconectar-se com um outro sistema de outro fabricante, de acordo com o
modelo de referência OSI.

Quanto a estrutura do modelo de referência OSI, a mesma é

apresentada em 7 (sete) camadas hierárquicas ou níveis. Sua estruturação
pode ser vista na figura 2.1.

APLICAÇÃO

APRESENTAÇÃO

SESSÃO

TRANSPORTE

REDE

ENLACE

FÍSICO
Figura 2.1 - O modelo de referência OSI.

Esta técnica de estruturação permite que a rede de sistemas abertos

possa ser vista como uma composição lógica de sucessivos níveis, cada um
envolvendo o nível abaixo e isolando-o dos níveis superiores.
 A idéia básica de estruturar em camadas é a de que, cada nível forneça
informações para os serviços oferecidos pelos níveis inferiores assim como os
níveis superiores oferecem um conjunto de serviços para executar aplicações
distribuídas.

Um nível pode ser visto individualmente, conforme figura 2.2, como um

nível (N) tendo um nível (N+1) acima (nível superior) e um nível (n-1) abaixo
(nível inferior). O nível (N) recebe serviços do nível (N-1) e fornece serviços ao
nível (N+1).

Cada nível contém um grupo lógico de funções que fornecem os

serviços específicos para facilitar a comunicação. O grupo de funções de um
nível cria uma unidade funcional que é chamada de entidade. Uma entidade
aceita uma ou mais entradas (argumentos) e produz determinadas saídas
(valores) dependendo da natureza das funções que executa. Lá podem ter
duas ou mais instâncias de entidades ativas dentro de cada nível executando
as funções para o suporte da comunicação.

Existem também interações entre entidades de níveis adjacentes, na

forma de requisições, indicações, respostas e confirmações, estas são
chamadas de primitivas. Cada primitiva pode também ter parâmetros
associados que transportam o controle da informação necessária para suportar
a comunicação.

NÍVEL (N+1) A B

NÍVEL (N) NÍVEL

ENTIDADE

NÍVEL (N-1)
A B
A: Serviços do Nível B: Prim itivas / Parâm etros

Figura 2.2 - Conceito de um nível no modelo OSI.

 Existe uma entidade ativa, para cada nível, em cada sistema envolvido
na interconexão. Entidades de um mesmo nível se comunicam com outra
usando um protocolo exclusivo ao seu nível que transporta o controle da
informação necessária para suportar a comunicação entre as aplicações
cooperantes.

As informações são trocadas entre as entidades de mesmo nível,

através da utilização de serviços do nível (N-1), que fornece uma conexão
lógica entre a entidade de nível (N). Em contrapartida, cada nível utiliza os
serviços do nível inferior, que são refletidos como serviços (N-1), conforme
figura 2.3.

PROTOCOLO PARA
ENTIDADE ENTIDADE
(N) (N)
O NÍVEL (N)

NÍVEL (N)

NÍVEL(N-1)

CONEXÃO (N-1)

Figura 2.3 - Conexão (N-1).

As primitivas também iniciam uma ação ou levam ao resultado de uma

ação, conforme figura 2.4.

SERVIÇO USUÁRIO SERVIÇO FORNECIDO SERVIÇO USUÁRIO

REQUEST INDICATION

CONFIRMATION RESPONSE

Figura 2.4 - Interação entre primitivas.

 As primitivas são:
Request - É iniciada do nível (N+1) para o nível (N) para ativar um
serviço particular.

Indication - É fornecido pelo nível (N) para levar a ativação de um

serviço particular.

Response - É fornecido pelo nível (N+1) em resposta para uma

primitiva INDICATION.

Confirm - É retornada para o nível (N+1) requisitante pelo nível (N)

sobre o serviço solicitado.

Os três níveis superiores fornecem as funções para suporte direto dos

processos de aplicações, enquanto que os três níveis inferiores interessam-se
com a transmissão de informação entre os sistemas-fins. O nível de transporte
é a ligação essencial destes dois grupos de funções, ele fornece integridade
fim-a-fim da comunicação, garantindo a qualidade apropriada do serviço dos
três níveis inferiores e os requisitos dos três níveis superiores [FOLT82].

Apesar do modelo de referência OSI ter sido apontado como a chave

para a interconexão de sistemas heterogêneos, alguns autores apontam certas
necessidades não conseguidas pelo modelo.

Svobodova [SVOB90] aponta, que apesar do modelo de referência OSI

ter sido concebido para prover uma solução unificada para a interconexão e
interoperabilidade entre sistemas e redes desenvolvidas por diferentes
fabricantes existem alguns pontos não atingidos. Para Svobodova, o problema
da interoperabilidade global ainda não foi solucionado. Esta situação é um
resultado de diversos fatores, mas o grande problema complicador é a grande
heterogeneidade dos ambientes endereçados pelos padrões. Continua
mostrando que, em redes de computadores, heterogeneidade mostra três
níveis básicos e que nem todos são abrangidos pelo modelo OSI. Os três
níveis são os seguintes:

Hardware e software que formam os sistemas a serem

interconectados;
 Meio físico e protocolos das subredes aos quais os diferentes
sistemas serão interconectados;

Protocolos de alto nível usados para a comunicação fim-a-fim

entre os sistemas.

Conclui, apontando que a heterogeneidade de sistemas e redes não é

causada somente pela inclusão de mecanismos apropriados dentro do modelo
OSI, mas também pelo aparecimento de diferentes tipos de serviços e
protocolos para um simples nível.
2.2 A arquitetura TCP/IP - Transport Control Protocol / Internet
Protocol

Em 1973, a Agência de Projetos de Pesquisa Avançada para Defesa

(Defense Advanced Research Projects Agency - DARPA), decidiu pela
necessidade de novos protocolos host-to-host na ARPANET. Estes novos
protocolos deveriam suportar diferentes técnicas de comunicação. As novas
implementações foram completadas em 1974. Em 1978, após quatro anos de
testes e refinamentos, o Departamento de Defesa norte-americano
(Departament of Defense - DoD) promulgou versões de TCP/IP (Transmission
Control Protocol/Internet Protocol) e obrigou o seu uso como padrão do DoD.

Os protocolos Internet, como é mais conhecida a arquitetura TCP/IP,

são projetados para redes de pacotes, que fornecem a entrega confiável de
mensagens ou notificações de falhas. Este modelo conduz ao uso de, no
mínimo, dois níveis de protocolo. O primeiro nível opera de forma fim-a-fim
entre os dois hosts envolvidos em uma conversação. O segundo nível é
baseado em um protocolo de baixo nível que trabalha na forma de passar-
adiante a mensagem, fazendo com que a mensagem percorra uma série de
elementos intermediários até chegar ao destino [LEFF88].

O TCP/IP também pode ser dividido em camadas, assim como o modelo

de referência OSI, porém alguns autores trazem formas diferentes de
representação. A seguir, na figura 2.5, está a visão de Leffler.

APLICAÇÃO

TCP UDP

IP ICMP

INTERFACE DE REDE

Figura 2.5 - Estruturação em camadas do TCP/IP segundo [LEFF88].

Ainda segundo Leffler, o Protocolo Internet ou IP como é conhecido, é

um protocolo de baixo nível e cabe a este elemento enviar a mensagem do
host origem, através de elementos intermediários, para o host destino. Este
nível corresponde ao Nível de Rede do modelo OSI. O IP deve fornecer
serviços a nível de rede para o endereçamento do host, roteamento, e se
necessário, fragmentação e montagem dos pacotes, caso a rede não consiga
enviar a informação em um único pacote.

O Transmission Control Protocol (TCP) e o User Datagram Protocol

(UDP) são protocolos do nível de transporte que fornecem facilidades
adicionais ao IP. No caso do TCP, este fornece confiança, não duplicação e
fluxo de transmissão controlado. Já o UDP oferece um mecanismo para
checar a integridade dos dados. Para finalizar, o Internet Control Message
Protocol (ICMP) é usado para relatar erros e outras tarefas de gerenciamento
da rede, este não é utilizado pelo usuário.

Os protocolos Internet são projetados para suportar sistemas e

arquiteturas heterogêneas. Sistemas que usam uma variedade muito grande de
representação interna de dados. Mesmo a unidade básica de dados, o byte,
não e o mesmo para todos os sistemas. Os protocolos de rede, no entanto,
requerem uma representação padrão, esta representação é obtida através de
octetos, um byte de oito bits.

Conforme citado anteriormente outros autores representam de forma

diferente as camadas do TCP/IP. [CHRI91] e [COME88] representam a
estrutura do TCP/IP como mostrada na figura 2.6.
A P L IC A Ç Ã O

TCP

IP

ARP

UDP

IN T E R F A C E D E R E D E

Figura 2.6 - Estruturação em camadas do TCP/IP segundo [CHRI91] e

[COME88].

Nesta nova representação, surge mais um elemento, o ARP (Address

Resolution Problem), que permite a um host encontrar um endereço físico de
um host destino na mesma rede física, tendo somente o endereço Internet do
destino.
 Um sistema de comunicação é dito com suporte de serviços de
comunicação universal se permitir que qualquer host possa se comunicar com
qualquer outro host. Para se estabelecer este sistema de comunicação
universal, é necessário estabelecer um método de identificação de
computadores aceito globalmente [COME88].

Partindo desta premissa, o endereço dos host Internet é um número de

32 bits (4 octetos), que identifica a rede em que o host está localizado e o
próprio host naquela rede. O endereço da rede é atribuído por uma agência
central e o endereço do host na rede é atribuído pelo administrador da rede. É
possível que um host esteja ligado a várias redes, isto implica que ele possuirá
múltiplos endereços.

Cada host é conhecido por um número da ARPANET IMP em cada rede

em que estiver conectado e por um número de porto naquele IMP (Interface
Message Processor). O IMP e os endereços do host ocupam um octeto do
endereço. Um dos dois octetos restantes é usado para designar a rede e o
outro fica disponível para ser usado como identificador de conexão
multiplexada.

Existem também algumas classes de endereços, como mostrado na

figura 2.7, que são determinadas pelos bits mais significativos. As classes são
definidas como sendo A, B e C, com os bits mais significativos assumindo 0, 10
e 110 respectivamente e usam 8, 16 e 24 bits respectivamente, para a parte de
endereço da rede.
HO S T
REDE IM P HO S T
L Ó G ICO
ENDEREÇO ARPANET

REDE HO S T
0 8 BIT S 24 BIT S

E N D E R E Ç O CL A S S E A

REDE HO S T
10 16 BIT S 16 BIT S

E N D E R E Ç O CL A S S E B

REDE HO S T
110 24 BIT S 8 BIT S

E N D E R E Ç O CL A S S E C

Figura 2.7 - Classes de endereços.

 Cada classe tem menos bits para a parte relativa ao endereço do host e
assim suporta menos hosts que a classe mais alta. Esta forma de codificação
suporta um grande número de redes de tamanhos variados, e mantendo ainda
a compatibilidade com o antigo código de endereços da ARPANET, porém, a
popularidade atingida pela rede Internet está levando os seus administradores
a buscarem novas alternativas de endereçamento.

A popularidade atingida pelo TCP/IP deve-se a cinco características

essenciais que a DARPA identificou como objetivos do projeto [SPAN88]:

Confiabilidade - é certamente a mais importante característica do

TCP/IP. O IP, como projetado, não se responsabiliza pela
confiabilidade dos dados entregues, ele simplesmente garante a
entrega para a rede apropriada. O TCP é quem fornece a
confiabilidade, através do método full duplex e comunicação
orientada a conexão entre os processos cooperantes.

Interoperabilidade - esta refere-se a habilidade de sistemas de

computadores diferentes comunicarem-se entre si. A
interoperabilidade é conseguida com três utilitários: FTP (File
Transfer Protocol), TELNET (serviço de terminal virtual) e SMTP
(Simple Mail Transport Protocol). Estes utilitários definem a interface
entre o software do usuário com o software dos níveis de transporte
e de rede que permite diferentes implementações tornarem-se
compatíveis.

Segurança - o IP inclui diversos campos dentro do cabeçalho que

permitem uma proteção seletiva da informação. No momento do
estabelecimento da conexão, as entidades devem concordar com os
níveis de segurança das informações associada para a conexão.

Flexibilidade e habilidade para permitir a transição entre

protocolos - o uso do TCP/IP não impõe regras quanto a meios ou
aplicações para o uso. Quando o TCP/IP requer certas coisas de
outros protocolos, ele utiliza primitivas que permitem a combinação.
Isso se deve ao fato do TCP/IP ser heterogêneo por natureza,
garantindo a migração para outros protocolos.
2.3 A arquitetura SNA - System Network Architecture

SNA (System Network Architecture) é uma arquitetura complexa e

sofisticada da IBM que define procedimentos e estrutura de comunicações de
entrada e saída de um programa de aplicação e a tela de um terminal, ou ainda
entre dois programas de aplicação. SNA consiste em um conjunto de
protocolos, formatos e sequências operacionais que controlam o fluxo de
informação dentro de uma rede de comunicação de dados ligada a um
mainframe IBM, micro computadores, controladoras de comunicação e
terminais.

A arquitetura SNA implementa um relacionamento hierárquico, também

chamado de mestre-escravo, o que implica em que um participante de uma
interação deve buscar permissão de um outro participante antes da interação
ser iniciada. Redes seguindo este modelo, são menos flexíveis para
estabelecer relacionamentos entre entidades arbitrárias, mas são mais
controláveis pelo gerente da rede [DEIT90].

Conforme o histórico relatado em [MEIJ88], a arquitetura SNA foi

anunciada em 1974, porém sofreu diversas alterações até ser o que é hoje. No
início era muito limitada quanto a abrangência e funções, mas fornecia os
mecanismos básicos necessários para o projeto de sistemas de comunicação.

As primeiras versões ficaram conhecidas como SNA 0 e 1 e fornecia

apenas funções limitadas. O maior propósito era o de possuir uma arquitetura
bem estruturada basicamente era constituída de um computador central (host),
um ou mais controladores de canais de comunicação ligados ao host e alguns
controladores de cluster, ou seja, definia três tipos de nodos:

.o nodo host;

.o nodo controlador de comunicação;

.o controlador de cluster.

Na versão seguinte, SNA 2 também em 1974, algumas melhorias

significativas foram introduzidas, tais como:
 .ligação local de controladores de cluster;

.controladores de comunicação remota;

.mais um tipo nodo (Terminal);

.suporte ao chaveamento de linhas de comunicação.

Porém estas melhorias não ampliaram o escopo da arquitetura. Isto só

ocorreu com a versão, SNA 3 - 1976, também conhecida por Funções de
Comunicação Avançada (SNA/ACF - Advanced Communications Functions).
Nesta versão eram permitidos que vários hosts fossem interligados através do
controlador de comunicação local.

A versão SNA 4 - 1979, removia algumas restrições que existiam nas

versões anteriores. Uma importante melhoria do ponto de vista arquitetural foi a
introdução de sessões paralelas entre hosts.

Em 1982, foi anunciado um produto chamado de Comunicação

Avançada de Programa a Programa (APPN - Advanced Program to Program
Communication), e em 1983 foi anunciado um outro produto que garantiria a
interligação de redes SNA independentes através de um gateway.

Assim uma rede SNA passou a consistir em um ou mais domínios, onde

um domínio se refere a todos os componentes físicos e lógicos que estão
conectados e são controlados por um ponto comum da rede. Este ponto
comum de controle é chamado de SSCP (System Services Control Point). São
três os tipos de unidades endereçáveis da rede (NAU - Network Address Unit)
[ALVE92]:

.SSCP (System Services Control Point);

.PU (Physical Units);

.LU (Logical Units).

 O SSCP consiste em um método de acesso de comunicação operando
em um mainframe IBM. Ele contém as tabelas de endereçamento da rede,
tabelas de roteamento e tabelas de tradução, que são empregadas para
estabelecer conexões entre os nós da rede e controlar o fluxo de informação.

Cada domínio contém um ou mais nós, consistindo a rede SNA em um

agrupamento de componentes de rede. Exemplos de nós SNA incluem os
controladores de cluster, controladores de comunicações e terminais, com o
endereço de cada dispositivo na rede.

Cada nó SNA contém uma unidade física (PU), que controla os outros
recursos contidos neste nó. A unidade física (PU) não é um dispositivo físico,
mas um conjunto de componentes que fornece serviços usados para controlar
recursos como terminais, controladoras, processadores e linhas. Ou ainda, as
unidades físicas são representações de dispositivos e linhas de comunicação
da rede [TILL90].

Já o último tipo de unidade endereçável da rede é a unidade lógica

(LU), esta serve como ponto de acesso para que os usuários possam utilizar a
rede. Cada unidade física (PU) pode ter uma ou mais unidades lógicas, onde
cada unidade lógica tem um endereço distinto.

Existem os seguintes tipos de unidades físicas:

.terminais;

.controladores de cluster;

.processadores front-end (FEP);

.hosts.

Sendo que os terminais e os controladores de cluster são considerados

nodos periféricos, que são aqueles que se comunicam apenas com os nodos
subáreas em que estão conectados. E os processadores front-end e os hosts
são tipos de nodos subáreas, ou seja, além de se comunicarem com seus
próprios periféricos, possuem habilidade para se comunicarem com outros
nodos subáreas da rede.
 Com respeito a estabelecimento de sessões, [KONA83] e [ALVE92],
colocam que uma sessão na arquitetura SNA pode ser definida como a
conexão lógica entre duas unidades endereçáveis da rede para troca de
informação entre estas. As funções necessárias para o estabelecimento e
gerenciamento destas sessões estão contidas nos vários níveis da arquitetura
da rede.

Assim como nas arquiteturas anteriores, SNA também é dividida em

camadas, alguns autores diferem quanto a sua representação hierárquica. Isto
pode ser comprovado comparando a figura 2.9, que traz as visões de [SY 87]
e [TILL90], com a figura 2.10, que mostra a visão de [KONA83].

SERVIÇO TRANSAÇÃO USUÁRIO FINAL

SERVIÇO APRESENTAÇÃO SERVIÇO APRESENTAÇÃO

CONTROLE FLUXO DADOS CONTROLE FLUXO DADOS

CONTROLE TRANSMISSÃO CONTROLE TRANSMISSÃO

CONTROLE PATH CONTROLE PATH

CONTROLE LIGAÇÃO CONTROLE LIGAÇÃO

Figura 2.10 - Representação do modelo

CONTROLE FÍSICO
SNA por [KONA83]
Figura 2.9 - Representação do modelo
SNA por [SY87] e [TILL90]
2.4 A arquitetura XNS - Xerox Network Services

A Xerox Network Services é uma arquitetura de rede desenvolvida pela

Xerox Corporation em meados de 1970. Seu objetivo, na época, era interligar
os escritórios da companhia ao sistema de computadores.

XNS é um sistema aberto, podendo ser encontrado hardware e software

que o suportam em diversos ambientes e plataformas operacionais. Sua
operação é similar a do TCP/IP, tanto na estruturação quanto nos serviços
oferecidos, como serviços orientados à conexão ou não, por exemplo.

Uma comparação entre a estruturação de camadas da arquitetura XNS

com o modelo de referência ISO-OSI pode ser visto na figura 2.11. Nesta
representação, são apresentados vários componentes que compõem o nível de
transporte da XNS, porém, é interessante observar que, não são todos os
componentes que trocam informações com os processos de usuários, isto
porque alguns componentes (ECHO, RIP e ERROR) neste nível que exercem
funções próprias para manter o protocolo funcional.

APLICAÇÃO

APRESENTAÇÃO Processos de Usuários

SESSÃO

TRANSPORTE ECHO RIP PEX SPP ERROR

REDE IDP

ENLACE
Interface Hardware
FÍSICO
Figura 2.11 - Estrutura da arquitetura XNS em comparação com o modelo ISO-
OSI.

Cada um dos componentes que compõe a arquitetura XNS possui

funções específicas, as quais são interessantes conhecer. São elas:
 ECHO - Echo Protocol - É um protocolo que permite ao equipamento
host transmitir o pacote que acabou de receber.

RIP - Routing Information Protocol - É um protocolo usado para manter

uma base de dados sobre roteamento que serve ao host para enviar os
pacotes IDP para outros hosts.

PEX - Packet Exchange Protocol - É um protocolo não orientado á

conexões, que disponibiliza o uso de datagramas para os processos de
usuários.

SPP - Sequenced Packet Protocol - É um protocolo orientado à conexão,

que permite uma confiabilidade maior que o PEX na entrega da
informação, isto devido a alguns mecanismos de controle que possui.

ERROR - Error Protocol - É o protocolo responsável pela descoberta dos

erros ocorridos na comunicação.

IDP - Internet Datagram Protocol - É um protocolo não orientado à

conexão, que disponibiliza um serviço de entrega de pacotes para todos
os protocolos do nível superior.

Tanto o SPP quanto o PEX são protocolos a nível de transporte

disponibilizado na arquitetura XNS; a diferença entre ambos reside no fato de
que o SPP oferece um serviço orientado à conexão com troca de informações
entre as partes envolvidas na comunicação de maneira confiável e full-duplex.
Já o PEX disponibiliza um serviço não orientado à conexão, com as referidas
conseqüências deste tipo de serviço, ou seja, não segurança da entrega das
informações e falta de confiabilidade nos dados.

A representação 2.12 mostra a interação entre os processos de usuários

com os protocolos do nível de transporte, bem como a comunicação do
processo de usuário diretamente com o IDP, visto que é possível.

O modelo XNS foi muito bem aceito pelos usuários e desenvolvedores,

tanto que modelos alternativos foram desenvolvidos tomando como referência
o modelo XNS, é o caso do SPX/IPX da Novell, que é apresentado a seguir.
 Para maiores informações a respeito da arquitetura XNS, consultar
[STEV90].

Processo de Processo de Processo de

U suário U suário U suário

SP P PEX
(Transporte) (Transporte)

ID P

Interface
H ardware

Figura 2.12 - A comunicação entre processos de usuários e componentes de

transporte XNS.
2.5 A arquitetura SPX/IPX - Sequenced Packet
Exchange/Internet Packet Exchange

SPX/IPX (Sequenced Packet eXchange/Internet Packet eXchange) é o

protocolo de comunicação desenvolvido pela Novell para suas redes Netware.
Ele é um subconjunto da arquitetura Xerox Network Services (XNS [STEV90]).
SPX/IPX é similar à arquitetura TCP/IP em termos de funcionalidade e
compatibilidade com os níveis do modelo ISO-OSI. A respeito desta
compatibilidade, o IPX corresponde ao protocolo de rede e o SPX ao de
transporte, como mostra a representação 2.13.

APLICAÇÃO

APRESENTAÇÃO

SESSÃO

SPX TRANSPORTE

IPX REDE

ENLACE

FÍSICO

Figura 2.13 - Comparação da arquitetura SPX/IPX com a arquitetura ISO-OSI.

A arquitetura em questão permite utilizar-se dos serviços orientados e

não orientados à conexão, sendo que o primeiro é realizado por intermédio do
SPX, que garante a entrega da informação, monitorando as transmissões e
retransmitindo se os respectivos reconhecimentos não retornarem; e o
segundo serviço é realizado pelo IPX, que têm como função endereçar e rotear
os pacotes aos seus destinos.

A maneira como ambos atuam é apresentada na figura 2.14. No caso do

SPX, o processo do usuário envia e recebe informações diretamente deste
nível (A), e este transfere as mensagens, depois de devidamente
seqüêncializadas, para o nível inferior (B), no caso o IPX. O simples fato de
utilizar-se das funções disponibilizadas pelo SPX, com seus respectivos
parâmetros, garante à aplicação estar utilizando o serviço orientado à conexão.

E caso o desenvolvedor necessite utilizar os serviços não orientados a

conexão, deverá implementar em sua aplicação as funções que fazem acesso
direto ao IPX (C). Porém, neste caso, a aplicação ficará encarregada de efetuar
todo o controle para garantir a confiabilidade da informação, um vez que o IPX
é apenas um entregador de mensagens, não realizando controles sobre as
mesmas.

P ro cess o d e
U s uá rio

SPX C

IP X

Figura 2.14 - Fluxo da informação entre processo de usuário, SPX e IPX.

Uma aplicação não fica restrita apenas a uma conexão ou ligação

externa, um mesmo processo pode estar com conexões abertas com n outros
processos, ou ainda despachando informações para todos os usuários de uma
rede. Esta flexibilidade pode ser vista na representação 2.15, onde um único
processo cliente pode estar se comunicando com um processo servidor
qualquer através do SPX e mantendo contato com outros processos clientes
através do IPX.

Como nas outras arquiteturas, o SPX/IPX disponibiliza algumas funções

para que os desenvolvedores de aplicações possam utilizar seus serviços. A
tabela 2.3 mostra estas funções, bem como seus parâmetros.

As funções fazem referência a uma estrutura de bloco de controle de

eventos (ECB - Event Control Block), é a estrutura de dados mais importante
do protocolo, visto que armazena endereços, buffers de recepção e
transmissão, além de informações sobre a conexão local e remota.
 Processo Processo Processo
Cliente Cliente Cliente

SPX SPX SPX

IPX IPX IPX

IPX

SPX

Processo
Servidor

Figura 2.15 - Comunicação entre processos clientes e servidor.

2.6 Equivalência de serviços entre as arquiteturas OSI, TCP/IP e
SPX/IPX

Com base nas funções e chamadas levantadas nos itens anteriores,

pôde-se apontar para certas equivalências entre os serviços oferecidos pelas
arquiteturas OSI, TCP/IP e SPX/IPX.

Sobre os tipos de serviços, fica evidenciado que as três arquiteturas de

redes aqui mencionadas fornecem serviços orientados e não orientados à
conexão. Algumas de maneira mais simples e outras nem tanto.

Comparações entre as chamadas das arquiteturas podem ser vistas

nesta e nas páginas que seguem.

ISO-OSI para TCP/IP

ISO-OSI TCP/IP
T_CONNECT_REQUEST ACTIVE OPEN
T_CONNECT_INDICATION sem equivalência
T_CONECT_RESPONSE ACTIVE OPEN
T_CONNECT_CONFIRMATION OPEN ID, OPEN SUCCESS
T_DATA_REQUEST SEND sem URGENT FLAG
T_DATA_INDICATION RECEIVE sem URGENT FLAG
T_EXPEDITED_DATA_REQUEST SEND com URGENT FLAG
T_EXPEDITED_DATA_INDICATION RECEIVE com URGENT FLAG
T_DISCONNECT_REQUEST ABORT
T_DISCONNECT_INDICATION CLOSE, TERMINATE

Tabela 2.4 - Equivalência do modelo ISO-OSI para TCP/IP.

ISO-OSI para SPX/IPX

ISO-OSI SPX/IPX
T_CONNECT_REQUEST SPXEstablishConnection
T_CONNECT_INDICATION SPXEstablishConnection
T_CONECT_RESPONSE sem equivalência
T_CONNECT_CONFIRMATION sem equivalência
T_DATA_REQUEST SPXSendSequencedPacket
T_DATA_INDICATION SPXListenForSequencedPacket
T_EXPEDITED_DATA_REQUEST sem equivalência
T_EXPEDITED_DATA_INDICATION sem equivalência
T_DISCONNECT_REQUEST sem equivalência
T_DISCONNECT_INDICATION SPXTerminateConnection
Tabela 2.5 - Equivalência do modelo ISO-OSI para SPX/IPX

TCP/IP para ISO-OSI

TCP/IP ISO-OSI
PASSIVE OPEN sem equivalência
ACTIVE OPEN T_CONNECT_REQUEST
T_CONNECT_RESPONSE
SEND sem URGENT FLAG T_DATA_REQUEST
SEND com URGENT FLAG T_EXPEDITED_DATA_REQUEST
ALLOCATE sem equivalência
CLOSE T_DISCONNECT_INDICATION
ABORT T_DISCONNECT_REQUEST
STATUS sem equivalência
OPEN ID T_CONNECT_CONFIRMATION
OPEN FAILURE T_DISCONNECT_INDICATION
OPEN SUCCESS sem equivalência
RECEIVE sem URGENT T_DATA_INDICATION
FLAG
RECEIVE com URGENT T_EXPEDITED_DATA_INDICATION
FLAG
CLOSING sem equivalência
TERMINATE sem equivalência
STATUS RESPONSE sem equivalência
ERROR sem equivalência
Tabela 2.6 - Equivalência de TCP/IP para modelo ISO-OSI.
TCP/IP para SPX/IPX

TCP/IP SPX/IPX
PASSIVE OPEN SPXListenForConnection
ACTIVE OPEN SPXEstablishConnection
SEND sem URGENT FLAG SPXSendSequencedPacket
SEND com URGENT FLAG sem equivalência
ALLOCATE SPXInitialize
CLOSE SPXTerminateConnection
ABORT sem equivalência
STATUS sem equivalência
OPEN ID SPXOpenSocket
OPEN FAILURE SPXOpenSocket
OPEN SUCCESS SPXOpenSocket
RECEIVE sem URGENT SPXListenForSequencedPacket
FLAG
RECEIVE com URGENT sem equivalência
FLAG
CLOSING sem equivalência
TERMINATE SPXTerminateConnection
STATUS RESPONSE sem equivalência
ERROR sem equivalência
Tabela 2.7 - Equivalência de TCP/IP para SPX/IPX.

SPX/IPX para ISO-OSI

SPX/IPX ISO-OSI
SPXEstablishConnection T_CONNECT_REQUEST
T_CONNECT_INDICATION
SPXInitialize sem equivalência
SPXListenForConnection sem equivalência
SPXListenForSequencedPack T_DATA_INDICATION
et
SPXSendSequencedPacket T_DATA_REQUEST
SPXTerminateConnection T_DISCONNECT_INDICATION
SPXCheckSocket sem equivalência
SPXOpenSocket sem equivalência
Tabela 2.8 - Equivalência de SPX/IPX para modelo ISO-OSI
SPX/IPX para TCP/IP

SPX/IPX TCP/IP
SPXEstablishConnection ACTIVE OPEN
SPXInitialize sem equivalência
SPXListenForConnection PASSIVE OPEN
SPXListenForSequencedPack RECEIVE
et
SPXSendSequencedPacket SEND
SPXTerminateConnection TERMINATE
CLOSE
SPXCheckSocket OPEN SUCCESS
SPXOpenSocket OPEN SUCCESS

Tabela 2.9 - Equivalência de SPX/IPX para TCP/IP.

É interessante salientar que as equivalências aqui levantadas são

relativas aos tipos de serviços que as arquiteturas fornecem e não pela sua
forma de utilização.
3 APIs - Applications Programs Interfaces

Assim como ocorre com as arquiteturas de redes, as APIs podem ser

encontradas em vários tipos, de acordo com o tipo de sistema onde se esta
trabalhando.

A diversidade de tipos, formas de trabalho, além da interação, acabam

por incidir diretamente na interoperabilidade entre as aplicações, o que pode
levar uma aplicação à atingir um alto ou baixo grau de interoperação.

Este capítulo procura reunir algumas das APIs mais utilizadas, buscando
identificar características operacionais dos mesmos e detectar possíveis casos
de interoperabilidade.

3.1 O mecanismo NetBIOS

Em 1984, a IBM elaborou sua primeira rede local, a IBM PC Network,

com o objetivo de interligar computadores pessoais, todos compartilhando um
mesmo meio físico; e, projetou o NetBIOS para ser o controlador da mesma.

O termo NetBIOS é derivado de Net (Network) e BIOS (Basic Input

Output System), sendo que todas as rotinas ficavam armazenadas dentro de
uma memória somente de leitura e esta, por sua vez, localizava-se na placa de
rede, chamada pela IBM como "placa adaptadora".

Atualmente, o NetBIOS pode ser encontrado sobre placas Ethernet e

Token Ring, podendo assim ser utilizado por uma maior quantia de usuários e
sistemas de redes, além de não necessitar mais ser implementada em
hardware, podendo ser considerada como uma camada adicional de software.

Seguindo a linha de produtos compatíveis, o NetBIOS mantém ligação

com o modelo de referência ISO-OSI, como pode ser visto na figura 3.1. A
interface de serviços NetBIOS pode ser encontrada englobando os níveis de
transporte e rede, ficando os níveis de aplicação, apresentação e sessão
abrangidos pelo processo do usuário e os níveis de enlace e físico
correspondendo à interface de hardware.

Quantos aos serviços disponibilizados, podem ser encontrados os

serviços de nomes, sessão (serviço orientado à conexão), datagramas (serviço
não orientado à conexão) e alguns comandos gerais. Existe um relacionamento
entre estes tipos de serviços, que pode ser observado na figura 3.2.

APLICAÇÃO
Processo do Usuário
APRESENTAÇÃO

SESSÃO

TRANSPORTE
Interface NetBIOS
REDE

ENLACE
Interface de Hardware
FÍSICO
Figura 3.1 - Relacionamento do NetBIOS com o modelo OSI.

Processo do Usuário

NetBIOS

Serviços de Serviços de Serviços de Comandos

Sessão Nomes Datagrama Gerais

Interface do Hardware

Figura 3.2 - Relacionamento entre serviços NetBIOS.

O relacionamento não é completo entre todos os serviços, como pode
ser visto; os comandos gerais somente se relacionam com os processos dos
usuários e com a interface de hardware e o serviço de nome serve como
centralizador dos serviços de datagrama (não orientado à conexão) e de
sessão (orientado à conexão).

Serviços de Nomes

Os nomes, no NetBIOS, são usados para identificar recursos e

processos, por exemplo, um processo cliente identifica um processo servidor
específico por um nome do servidor e o servidor pode determinar para que
deve enviar as informações através do nome do cliente.

Podem existir dois tipos de nomes; único e grupo, sendo que o primeiro
identifica apenas um elemento na rede, já o segundo consiste em um conjunto
com vários elementos da rede. Os comandos utilizados para manipular estes
nomes são aqueles apresentados na tabela 3.1.
ADD_NAME Adiciona um nome único
ADD_GROUP_NAME Adiciona um nome de grupo
DELETE_NAME Elimina um nome (único ou de
grupo)
FIND_NAME Encontra um nome, se existir
Tabela 3.1 - Comandos do serviço de nomes.

Serviços de Sessão

Estes serviços fornecem ao NetBIOS serviços orientados à conexão,

com confiabilidade e com características full duplex. Os dados são
armazenados dentro de mensagens e cada mensagem pode ter entre 0 e
131.071 bytes. Seus comandos podem ser vistos na tabela 3.2.

Serviços de datagrama

NetBIOS suporta serviços não orientados à conexão, com datagramas

de até 512 bytes, e como os demais equivalentes, não oferece garantias
quanto a confiabilidade dos dados transmitidos.
CALL Solicita uma conexão - active open.
LISTEN Aguarda solicitação de conexão - passive
open.
SEND Envia dados da sessão.
 SEND_NO_ACK Envia dados da sessão sem reconhecimento.
RECEIVE Recebe dados da sessão.
RECEIVE_ANY Recebe dados da sessão vindos de qualquer
cliente.
HANG_UP Encerra sessão.
SESSION_STATUS Mostra status da sessão.
Tabela 3.2 - Comandos do serviço de sessão.

Os datagramas podem ser enviados para um nome específico (único),

para grupos, ou ainda, para todos os nomes da rede. Os comandos usados
para trabalhar com esta modalidade são mostrados na tabela 3.3.

SEND_DATAGRAM Envia datagramas.

SEND_BROADCAST_DATAGRAM Envia datagramas na forma
broadcast.
RECEIVE_DATAGRAM Recebe datagramas.
RECEIVE_BROADCAST_DATAGRAM Recebe datagramas na
forma broadcast.
Tabela 3.3 - Comandos do serviço de datagrama.

Comandos Gerais

São comandos que não se enquadram nas especificações anteriores.

RESET Reinicializa o NetBIOS.

CANCEL Cancela um comando.
ADAPTER_STATUS Busca o status da placa.
UNLINK Elimina a ligação com o bootstrap do servidor
(para estações diskless).
Tabela 3.4 - Comandos gerais.

O fato do NetBIOS não necessitar mais ser implementado no hardware

da rede faz com que ele volte a ser utilizado muito hoje em dia, principalmente
em aplicações que trabalhem no esquema ponto-a-ponto.
3.2 O mecanismo RPC - Remote Procedure Call

Apesar da maioria dos sistemas possuírem formas para a sua

interligação, eles não possuem um protocolo comum para isso; e até mesmo
cada subconjunto de sistemas que compartilham um mesmo protocolo, podem
ser substancialmente diferentes entre si quanto a sua utilização. Sugere-se,
portanto, a utilização da chamada remota de procedimento para suprir esta
falta de padronização de protocolos [BERS87].

A chamada de procedimento é uma maneira de se transferir o controle

de um processo para outro, com o retorno do controle ao processo chamador.
Associado a chamada de procedimento, encontra-se a passagem de
argumento de um processo cliente para o processo servidor. O procedimento
cliente e o servidor residem em processos separados com endereços próprios,
não permitindo o conceito de variáveis globais como acontece em
procedimentos normais dentro de processos locais.

Processo Processo

Comunic. Comunic.
Local Local
Comunicação
Remota
Processo Processo

HOST B HOST A

Figura 3.3 - Comunicação local e remota entre processos.

Em muitos sistemas, tanto o cliente como servidor estão dentro de um

mesmo processo em um determinado sistema e existe uma ligação lógica entre
eles. Esta modalidade de chamada recebe o nome de chamada local de
procedimento. Porém, se um processo de um determinado sistema solicita um
procedimento de um processo de outro sistema, dá-se o nome de chamada
remota de procedimento ou RPC (Remote Procedure Call).
 O objetivo principal das chamadas remotas de procedimento (RPC) é o
de as tornarem tão simples como as chamadas locais de procedimento. Para
tanto, alguns pontos devem ser levados em consideração, tais como:

Passagem de parâmetros - A passagem de parâmetros entre cliente e

servidor pode não ser transparente, visto que existem problemas para
se passar parâmetros por referência. A maioria dos autores sugerem a
passagem apenas de parâmetros por valores.

Conexão (BINDING) - Consiste na conexão do sistema cliente com o

sistema remoto alvo para ter uma chamada remota executada. Ele deve
encontrar o sistema apropriado e o processo servidor naquele sistema.

Manipulação de erros - Com um procedimento local há um número

limitado de coisas que podem dar errado, porém ao utilizar sistemas
remotos, as possibilidade aumentam em muitas vezes, isto pelo fato dos
sistemas estarem fisicamente distantes e tornar-se um tanto complicado
recuperar-se de erros ocorridos.

Representação dos dados - Quando se utiliza uma chamada local,

tanto o cliente como o servidor estão executando em um mesmo
sistema, portanto, não existem problemas de compatibilidade de dados,
porém, isto pode não acontece quando se utiliza RPC, pois o cliente e o
servidor podem estar em arquiteturas distintas, e isso acarretará na
necessidade de conversão dos dados.

Desempenho - Normalmente o desempenho da chamada remota é

menor se comparada com a chamada local, porém RPC deve ser vista
como uma forma de utilizar procedimentos de outros sistemas e não
como uma sucessora das chamadas locais.
3.3 A interface Clean and Simple

A interface Clean and Simple - C & S - proposta em [COLE87], consiste

em um elemento projetado para ser uma interface de serviços de transporte
universal, suportando os mais variados serviços de transporte.

Esta interface compõem-se, basicamente, por duas partes: a primeira

está baseada no equipamento cliente que necessitará mapear suas
solicitações ou serviços para um protocolo diferente daquele que possui em
seu equipamento; já a segunda parte reside nos equipamentos servidores -
figura 3.4, os quais disponibilizarão seus serviços aos clientes .

Servidor TCP/IP

Rede A
Cliente

Servidor OSI
Sub Sistema de
Comunicação
Rede B

Cliente

Rede C

Cliente
Servidor SPX/IPX

Figura 3.4 - Representação da arquitetura utilizada pela interface C & S.

A maneira como a interface atua é relativamente simples e pode ser

compreendida tomando como referência a figura 3.5.

Seu funcionamento consiste em uma aplicação qualquer, desenvolvida

em um equipamento cliente, necessitar utilizar serviços de um protocolo que
não é o disponível em seu equipamento, ou então, ter acesso a uma rede que
utiliza um protocolo diferente daquele encontrado em seu ambiente.

A solução proposta pela interface C & S consiste em identificar as partes

dependentes do protocolo desejado e alterá-las, inserindo nas mesmas as
chamadas ou primitivas da interface C & S.

Após esta alteração, executa-se a aplicação e, as chamadas

introduzidas redirecionam a parte dependente de protocolo para um módulo da
interface residente no equipamento cliente, e este envia, na forma de
mensagem, a informação para o servidor daquele protocolo desejado e este
pode processar a solicitação ou transferir para uma outra rede.

A figura 3.5 demonstra o fluxo das ações descritas anteriormente.

Cliente Servidor

Aplicação Aplicação
Cliente Servidora

Módulo Módulo
C&S Sub Sistema de C&S
Cliente Comunicação Servidor

Figura 3.5 - Comunicação entre a aplicação cliente com a aplicação servidora.

A interface C & S implementa uma comunicação entre processos -

processo cliente e processo servidor, no caso - onde a parte dependente de
protocolo é passada como uma mensagem entre os processos envolvidos na
comunicação. O protocolo que gerência esta troca de informação recebe o
nome de IPCS (InterProcess Clean and Simple) [COLE87].

A representação 3.6 mostra como é efetuada a troca de mensagens

utilizando as primitivas write e read como exemplos.
 IPCS
Cliente Servidor
Write(parte_dep_protocol) Read(parte_dep_protocol)

Figura 3.6 - Representação do IPCS.

A interface C & S disponibiliza ao implementador uma variedade de

primitivas. Tais primitivas podem ser observadas na tabela 3.5.

Primitiva Funções
s
getid Retorna um handle que é usado nas primitivas seguintes.
O handle pode ser usado para interromper as primitvas
open ou listen, caso seja necessário.
open Dado um endereço destino como parâmetro, é feita uma
tentativa para abrir uma chamada.
listen Usa um endereço opcional, espera por uma requisição de
chamada.
read Copia dados disponíveis na entrada para o buffer do
usuário.
write Envia dados de um buffer do usuário para a conexão.
close Executa um encerramento controlado na conexão.
abort Fecha imediatamente a conexão e inicializa todos os
recursos.
reset Causa uma reinicialização na conexão.
Tabela 3.5 - Primitivas da interface C & S.

Caso o desenvolvedor ou usuário utilize esta interface para alterar sua

aplicação, este deverá, de posse do código-fonte da mesma, identificar todas
as partes dependentes de protocolo desejado e não disponibilizado no
equipamento e adicionar junto à elas as respectivas primitivas oferecidas pela
interface C & S, a fim de garantir a comunicação com o servidor do protocolo
pretendido.
3.4 O mecanismo Socket

Sockets são mecanismos de comunicação entre processos

implementados no sistema UNIX 4.3BSD e que permite a comunicação entre
processos dentro de um mesmo domínio e também com processos em
execução em sistemas remotos. Seu surgimento deu-se com o sistema
4.1cBSD em 1982 e ela vêm sendo aprimorada com o aparecimento de novas
versões.

A interface socket fornece canais de comunicação full duplex e atua

como um elemento que recebe as chamadas vindas do processo do usuário e
transmite-as ao protocolo de comunicação e este, por sua vez, se encarrega de
despacha-la para os níveis inferiores - interface de rede e meio físico - como
pode ser observado na figura 3.7.

Processo do Usuário

Kernel
Interface de Chamadas do Sistema de
Sockets

Protocolo de Comunicação
(TCP, UDP e outros)

Data Link Device Driver (Ethernet)

Figura 3.7 - Representação da Interface Socket em um sistema.

Na verdade, não existem conexões físicas estabelecidas entre os pontos
que se comunicam, mas somente conexões virtuais, uma vez que os sockets
implementam pontos de conexões abstratos que apenas existem durante a
comunicação, ou seja, são criados e destruídos dinamicamente.

Sockets disponibilizam aos usuários seus serviços através de chamadas

de sistema que devem ser adicionadas às aplicações para que possam efetuar
a troca de informação com outros processos, locais ou remotos.

A interface sockets permite ao usuário desenvolver aplicações que

utilizem os serviços orientados à conexão e não orientados à conexão. Sendo
que o primeiro garante a confiabilidade e integridade dos dados enviados e o
segundo garante uma maior praticidade no envio.

Dependendo do tipo de serviço desejado, deve-se utilizar certas

chamadas em detrimento de outras. As figuras 3.8 e 3.9 mostram como se
realiza a conversação entre os processos envolvidos, bem como as chamadas
que devem ser utilizadas.

Servidor

socket()
Cliente

bind() socket()

recvfrom() bind()

Bloqueado até receber

dados do cliente
Dados (Requisição)
sendto()

Requisição do
processo

Dados (Resposta)
sendto() recvfrom()

Figura 3.8 - Sockets usando serviço não orientado à conexão.

 Servidor

socket()

bind()

listen()
Cliente

accept() socket()

Bloqueado até receber

conexão do cliente
Estabelecimento de Conexão
connect()

Dados
read() (Requisição) write()

Requisição do
processo

Dados
write() (Resposta) read()

Figura 3.9 - Sockets usando serviço orientado à conexão.

É interessante complementar que socket abre uma real possibilidade de

se atingir a interoperabilidade entre aplicações em ambientes distintos,
principalmente se as aplicações envolvidas fizerem uso da arquitetura TCP/IP.
Os fatores que apontam para este sucesso são a ceitação das duas
tecnologias serem bem aceitas pela comunidade de desenvolvedores e
conseguirem facilmente interoperarem-se.

A facilidade da interoperação entre sockets e TCP/IP deve-se ao fato

deste último implementar a técnica de porto, que por sua vez é utilizada pelos
sockets. Um mesmo porto consegue gerenciar múltiplos sockets e isso permite
que várias aplicações estabeleçam conexões simultâneas com o mesmo porto.

Davidson mostra, em [DAVI92], que alguns portos têm seus endereços,

ou números, pré definidos e que um socket é composto por um endereço IP e
um porto. Sendo assim, alguns serviços básicos podem estar associados a
determinados portos e quando a aplicação desejar fazer uso deles, basta
conectar-se ao respectivo porto. A figura abaixo mostra dois sockets
conectando-se a um porto TCP para se utilizarem do serviço disponibilizado.
Socket
132.151.1.4,1055

C onexão
o

o Servidor TELNET

o Servidor TELNET

Socket
132.151.1.12,2111
Socket
132.151.11.1,23

(End. IP, porto)

Figura 3.10 - Sockets utilizando portos para conexão TCP/IP.

Na representação 3.10, pode-se observar que o porto 23 esta

gerenciando duas conexões, sendo que estas duas conexões estão fazendo
uso do serviço de comunicação TELNET.

A facilidade de se estabelecer comunicação entre aplicações que fazem

uso do socket e aplicações que fazem uso do TCP/IP, abre grandes horizontes
para se atingir a interoperabilidade, visto que a aplicação socket, baseada em
TCP/IP pode interagir-se com qualquer aplicação que esteja utilizando TCP/IP,
independente do tipo de plataforma ou sistema operacional que se esteja
utilizando.

Maiores informações sobre como implementar utilizando sockets podem

ser obtidas em [LEFF89] e [STEV90].
3.5 A biblioteca TLI - Transport Layer Interface

A TLI foi introduzida com a versão 3.0 do UNIX System V em 1986, com
a intenção de fornecer aos desenvolvedores uma interface a nível de transporte
baseado no modelo ISO-OSI.

Consiste em um conjunto de funções e pode ser dividida em duas

partes, a biblioteca TLI e o módulo TLI. A biblioteca TLI é composta pelas
funções propriamente ditas, que são disponibilizadas aos usuários e
desenvolvedores, para que estes Incorporem-nas em suas aplicações e o
módulo TLI é responsável pela adequação das funções à camada de transporte
disponível no ambiente. Ela é tão flexível que permite aos desenvolvedores
escrever aplicações sem se preocuparem com o tipo de transporte que se está
utilizando [DAVI92].

É interessante realçar que a TLI, biblioteca e módulo, não incorporam a

camada de transporte ao seu conjunto, sendo que este último fica a cargo do
ambiente. Isto garante à TLI uma flexibilidade muito grande, pois se um
desenvolvedor cria uma aplicação usando as funções da biblioteca em questão
sobre uma camada SPX, poderá levar esta mesma aplicação para um
ambiente OSI ou TCP/IP sem ter que reescrever o código, bastando recompilá-
la no ambiente desejado.

Esta flexibilidade é garantida pelo módulo TLI que ao detectar uma

função da biblioteca converte o formato da mensagem para o tipo de transporte
disponível. Esta vantagem é importantíssima para se atingir a
interoperabilidade entre aplicações.

A figura 3.11 traz o relacionamento da biblioteca TLI com o módulo TLI,

juntamente com a aplicação e outras partes envolvidas no processo.

Vê-se no topo da estrutura o módulo correspondente à aplicação do

usuário incorporando a biblioteca TLI, uma vez que tal aplicação efetua
chamadas da referida biblioteca.

A seguir encontra-se stream head, que executa a conversão do formato

da informação para uma forma entendida pelo nível inferior (módulo TLI).
 Aplicação

Biblioteca TLI

Stream Head

Módulo TLI

Módulo Transporte

Módulo Rede

Device Drivers

Figura 3.11 - Relacionamento da biblioteca TLI com o módulo TLI.

O módulo TLI atua como um conversor do formato da mensagem vinda

do nível superior para o módulo de transporte que se está utilizando naquele
momento.

Já os módulos de transporte, de rede e os device drivers têm a sua

atuação normalmente, gerenciando conexões, efetuando checagens e
correções, enfim, as tarefas que lhes são atribuídas.

Dentre as funções que são disponibilizadas pela TLI, podem ser

encontradas aquelas que permitem o uso de serviços orientados à conexão e
aquelas para serem utilizadas em serviços não orientados à conexão. Isto
ocorre pelo fato da TLI, assim com o TCP/IP e SPX/IPX, também disponibilizar
estes tipos de serviços, uma vez que o modelo ISO-OSI também o faz.
 Como mencionado anteriormente, a TLI permite a utilização dos serviços
orientados e não orientados à conexão. As figuras 3.12 e 3.13 demonstram
quais as funções que são utilizadas em cada caso, bem como a seqüência das
mesmas.

O único aspecto complicador em utilizar-se da TLI reside no fato de que,

se o usuário possuir aplicações e desejar utilizar-se da facilidades desta
biblioteca, deverá trocar as instruções de sua aplicação pelas funções TLI
correspondentes, ou então reescrever suas aplicações usando agora as novas
funções.
Servidor

t_open()

t_bind() Cliente

t_open()
t_alloc)

t_bind()
t_listen()

Bloqueado até receber t_alloc()

conexão do cliente

Estabelecimento de Conexão
t_accept() t_connect()

Dados (Requisição)
t_rcv() t_snd()

Requisição do
processo

Dados (Resposta)
t_snd() t_rcv()
 Figura 3.12 - Funções TLI para serviço orientado à conexão.

Servidor

t_open()

Cliente

t_bind() t_open()

t_alloc() t_bind()

rcvudata() t_alloc()

Bloqueado até receber

dados do cliente Dados (Requisição)
t_sndudata()

Requisição do
processo

t_sndudata() t_rcvudata()
Dados (Resposta)

Figura 3.13- Funções TLI para serviço não orientado à conexão.

4 Interoperabilidade e Interconectividade de sistemas

As dificuldades encontradas para se atingir a interconectividade e

interoperabilidade residem em adotar-se um padrão. Infelizmente, os esforços
em se seguir padrões imparciais sugeridos por orgão internacionais não têm
dado certo, visto que as definições oferecidas por estes orgãos as vezes não
coincidem com as necessidades ou aspirações do mercado; vide a tradicional
disputa ISO-OSI com TCP/IP.

No tocante a interconectividade, não existem tantos problemas, uma vez

que a comunidade de usuários e desenvolvedores parecem ter chegado a
padrões mais estáticos, utilizando Ethernet, Token Ring, ArcNet entre outros,
com suas respectivas topologias para efetuar a interligação entre os elementos
envolvidos no processo de comunicação.

Caso o interessado deseje interconectar ambientes de mesmo padrão,

ele pode fazer isto por intermédio de uma ponte e caso deseje interconectar
ambientes com padrões diferentes pode utilizar-se de um gateway, conforme
representação 4.1.

Lan Ethernet Ponte Lan Ethernet

Gateway
Lan Token
Lan Ethernet Ring

Figura 4.1 - Representação de uma ponte e um gateway.

 No caso de uma ponte, a informação vinda de uma rede é simplesmente
transferida para a outra rede, sem que exista a preocupação de alguma
espécie de transformação no formato dos pacotes. Esta mesma facilidade não
se obtém na utilização do gateway, uma vez que os pacotes deverão ter seus
formatos alterados para o tipo correspondente ao da rede destinatária. Porém,
se houver a necessidade de quaisquer mudanças, elas serão feitas pelos
próprios equipamentos envolvidos na operação, no caso, o gateway e a ponte,
não preocupando o usuário no que tange a sua aplicação.

Esta mesma transparência não é encontrada na interoperabilidade. A

interoperabilidade utiliza a interconectividade, atuando a nível de software,
portanto, cabe ao usuário observar e tratar as incompatibilidades entre as
partes envolvidas.

Uma prova de que as dificuldades em se atingir a interoperação são

muitas e de que os padrões também, pode ser observada no caso dos diversos
tipos de protocolos de transportes. Podem ser encontrados no mercado uma
grande variedade, como por exemplo os protocolos de transportes padrão OSI,
TCP/IP, SPX/IPX entre outros. Onde encontram-se uma compatibilidade a nível
de serviços oferecidos, mas não a nível de formato das chamadas, conforme
pode ser constatado no capítulo Arquiteturas.

Dentre as maiores dificuldades que os desenvolvedores encontram para

atingir a interoperabilidade, podem ser destacadas a maneira como as
aplicações envolvidas efetuarão a troca de informação, qual o formato da
informação, qual o protocolo envolvido na operação, a portabilidade de uma
aplicação para um outro ambiente distinto entre tantas outras.

Diante deste amontoado de dificuldades, os desenvolvedores têm

colocado seus conhecimentos para prover mecanismos que permitam superar
estes obstáculos. Alguns exemplos destes mecanismos podem ser
encontrados na literatura e mesmo em projetos práticos.

É o caso, por exemplo, de se construir aplicações gateways

responsáveis por receber, converter e despachar a informação, como sugere
[ROSE90] e muitos outros autores, ou então de se construírem primitivas que
direcionam a parte dependente de protocolo da aplicação para elementos
dedicados a determinados serviços de conversão, como acontece na interface
Clean and Simple [COLE87], adoção de filtros conversores para as aplicações,
ou ainda de se criar funções universais, que independem do tipo de protocolo e
formato da informação que serão utilizados, como mostra [STEV90] sobre a
TLI.

Enfim, existem uma série de mecanismos que buscam atingir a

interoperação, alguns conseguindo um maior grau e outros nem tanto, mas
todos buscando atingir seus objetivos.

No caso da utilização das aplicações gateways, a aplicação original não

será alterada, em conseqüência, existirá um módulo extra, ou um processo,
encarregado de receber as chamadas feitas pela aplicação, efetuar a alteração
e despachar para o processo destino; além é claro de executar o processo
inverso no caso de recebimento de informações, figura 4.2. Estas ações podem
comprometer o desempenho da aplicação, e em situações críticas, como
processamento em tempo real por exemplo, podem comprometer a
estabilidade do sistema.

A p lic a ç ã o
A p lic a ç ã o

A p lic a ç ã o
G atew ay

HOST A HOST B

Figura 4.2 - Utilização da técnica Aplicação Gateway.

Quanto à interface Clean and Simple (C & S), o usuário deverá alterar o
código fonte da aplicação, adicionando as primitivas que a interface
disponibiliza. Após esta atividade, necessita-se recompilar a aplicação e eleger
alguns computadores para serem os servidores de protocolos, que serão
encarregados de receberem as solicitações, processá-las e despacha-las às
redes destinatárias. Aqui o desempenho também pode ser afetado, visto que a
comunicação não é direta entre as partes envolvidas, mas sim através de um
elemento intermediário. A forma de funcionamento da C & S, bem como outros
detalhes, podem ser obtidos no capítulo APIs.

Os filtros aparecem como uma boa opção. Eles tomam o código fonte da
aplicação, analisam, e efetuam as alterações que forem necessárias. O
usuário, por sua vez, recompila a aplicação e esta passa a comunicar-se
diretamente com o ponto desejado; sem ter que trafegar por um elemento
intermediário.

O desempenho, na utilização dos filtros, estaria garantido, porém o fator

complicador nesta situação está em se conseguir filtros que convertam as
aplicações de forma completa, caso contrário, o usuário deverá interferir no
novo código fonte gerado e adequa-lo as suas reais necessidades.

Aplicação FILTRO Nova

A Aplicação A

Aplicação Comunicação Nova

B Aplicação A

HOST B HOST A

Figura 4.3 - Utilização da técnica de filtro.

Uma outra alternativa é a utilização da TLI, que oferece um conjunto de

funções que não estão ligadas diretamente a um protocolo; são funções
universais que podem ser mapeadas para todos os protocolos suportados pela
TLI. O desempenho fica garantido mas o usuário deverá escrever novamente
todas as suas aplicações, trocando as partes dependentes de protocolo pelas
funções TLI. Veja capítulo sobre API.
 Fica comprovado então que, apesar de existirem técnicas para se
buscar a interoperabilidade, estas não são completas; se elas não pecam pelo
desempenho, pecam pelo trabalho extra atribuído ao usuário ou vice-versa.

Conseqüentemente, não existe a melhor técnica, mas sim, a melhor

técnica para cada caso, que deve ser analisado previamente, considerando
todas as necessidades e implicações.

Texto gentilmente cedido por Flávio Toledo (flaviot@sti.com.br)

www.sti.com.br