1 Introduo

Os termos interoperabilidade e interconectividade so bastante usados hoje em dia, e muitos ainda apontam que estas duas palavras sero essenciais no que se refere a computao dos anos 90, mas por qu? A interconectividade refere-se a ligao fsica a ser estabelecida entre as partes que necessitam efetuar a comunicao, ou melhor, preocupa-se com as caractersticas fsicas, eltricas e mecnicas envolvidas neste processo de interligao. J o termo interoperabilidade, aponta para a capacidade de haver troca de informaes entre as aplicaes que esto sendo processadas nos computadores, e que estas informaes possam ser utilizadas para se atingir objetivos comuns, como o trabalho cooperativo, integridade, segurana dos dados e independncia de equipamentos. Para se usufruir da interconectividade e interoperabilidade torna-se necessrio a adoo de padres, coisas estas que at anteriormente no existiam, prova disso que os fabricantes de hardware e desenvolvedores de software desenvolveram cada um o seu prprio conjunto de regras. em meio a este cenrio que surge a necessidade de interligao de hardware e interoperao entre software. E por isso que os termos interconectividade e interoperabilidade sero palavras chaves nos anos 90, pois existe uma real necessidade de interligar todo este aparato tecnolgico existente e fazer com que seja realmente produtivo. Com esta viso, os fabricantes e desenvolvedores j procuram trabalhar seguindo padres sugeridos por orgos 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 padro para seu hardware e software, ou ento desenvolver algum produto que consiga comunicar-se com todos os padres 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 aplicaes mais difcil, 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 subsdios para se atingir a interoperabilidade e interconectividade.

2.1 O modelo OSI - Open System Interconnection

Em 1977, o comit tcnico 97 da ISO (International Organization for Standardization), reconheceu a necessidade de padres para redes de informaes heterogneas, e decidiu criar um novo subcomit (SC16) para estudar este problema e apresentar solues para a interconexo 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 definio, desenvolvimento e validao de padres na nova gerao de sistemas de informaes distribudas. O trabalho foi direcionado para definir a funcionalidade necessria comunicao entre processos de aplicaes localizadas remotamente em diferentes sistemas heterogneos [FOLT82]. O propsito deste modelo de referncia propor base comum para a coordenao da padronizao do desenvolvimento de todo e qualquer produto para a interconexo de sistemas de informao sem interferir no funcionamento interno do sistema individual [ALVE92]. Tarouco [TARO86] tambm apresenta que o modelo de referncia OSI foi criado com vistas a servir de base para a definio de projetos de padronizao da interconexo de sistemas abertos. A interconexo de sistemas abertos implica na conexo, por algum meio, de sistemas compreendendo computadores, seus perifricos, terminais, operadores humanos e processos fsicos.

O termo sistema deve ser entendido, como sendo um conjunto de um ou mais computadores, o software associado, seus perifricos, terminais, operadores humanos, processos fsicos, meios de transferncia de informao etc, que formam um todo capaz de executar processamento e/ou transferncia de informao. J o termo aberto (open), foi escolhido para enfatizar o fato de que, de acordo com os padres internacionais, um sistema deveria ser aberto para todos os outros sistemas, obedecendo os mesmos padres 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 referncia OSI. Quanto a estrutura do modelo de referncia OSI, a mesma apresentada em 7 (sete) camadas hierrquicas ou nveis. Sua estruturao pode ser vista na figura 2.1.

APLICAO APRESENTAO SESSO TRANSPORTE REDE ENLACE FSICO

Figura 2.1 - O modelo de referncia OSI. Esta tcnica de estruturao permite que a rede de sistemas abertos possa ser vista como uma composio lgica de sucessivos nveis, cada um envolvendo o nvel abaixo e isolando-o dos nveis superiores. A idia bsica de estruturar em camadas a de que, cada nvel fornea informaes para os servios oferecidos pelos nveis inferiores assim como os nveis superiores oferecem um conjunto de servios para executar aplicaes distribudas. Um nvel pode ser visto individualmente, conforme figura 2.2, como um nvel (N) tendo um nvel (N+1) acima (nvel superior) e um nvel (n-1) abaixo (nvel

inferior). O nvel (N) recebe servios do nvel (N-1) e fornece servios ao nvel (N+1). Cada nvel contm um grupo lgico de funes que fornecem os servios especficos para facilitar a comunicao. O grupo de funes de um nvel cria uma unidade funcional que chamada de entidade. Uma entidade aceita uma ou mais entradas (argumentos) e produz determinadas sadas (valores) dependendo da natureza das funes que executa. L podem ter duas ou mais instncias de entidades ativas dentro de cada nvel executando as funes para o suporte da comunicao. Existem tambm interaes entre entidades de nveis adjacentes, na forma de requisies, indicaes, respostas e confirmaes, estas so chamadas de primitivas. Cada primitiva pode tambm ter parmetros associados que transportam o controle da informao necessria para suportar a comunicao.
NVEL (N+1) A B

NVEL (N)

NVEL ENTIDADE

NVEL (N-1) A: Servios do Nvel

B: Primitivas / Parmetros

Figura 2.2 - Conceito de um nvel no modelo OSI. Existe uma entidade ativa, para cada nvel, em cada sistema envolvido na interconexo. Entidades de um mesmo nvel se comunicam com outra usando um protocolo exclusivo ao seu nvel que transporta o controle da informao necessria para suportar a comunicao entre as aplicaes cooperantes. As informaes so trocadas entre as entidades de mesmo nvel, atravs da utilizao de servios do nvel (N-1), que fornece uma conexo lgica entre a entidade de nvel (N). Em contrapartida, cada nvel utiliza os servios do nvel inferior, que so refletidos como servios (N-1), conforme figura 2.3.

ENTIDADE (N)

PROTOCOLO PARA O NVEL (N)

ENTIDADE (N)

NVEL (N) NVEL(N-1) CONEXO (N-1)

Figura 2.3 - Conexo (N-1). As primitivas tambm iniciam uma ao ou levam ao resultado de uma ao, conforme figura 2.4.
SERVIO USURIO SERVIO FORNECIDO SERVIO USURIO

REQUEST

INDICATION

CONFIRMATION

RESPONSE

Figura 2.4 - Interao entre primitivas. As primitivas so: Request - iniciada do nvel (N+1) para o nvel (N) para ativar um servio particular. Indication - fornecido pelo nvel (N) para levar a ativao de um servio particular. Response - fornecido pelo nvel (N+1) em resposta para uma primitiva INDICATION. Confirm - retornada para o nvel (N+1) requisitante pelo nvel (N) sobre o servio solicitado.

Os trs nveis superiores fornecem as funes para suporte direto dos processos de aplicaes, enquanto que os trs nveis inferiores interessam-se com a transmisso de informao entre os sistemas-fins. O nvel de transporte a ligao essencial destes dois grupos de funes, ele fornece integridade fim-a-fim da comunicao, garantindo a qualidade apropriada do servio dos trs nveis inferiores e os requisitos dos trs nveis superiores [FOLT82]. Apesar do modelo de referncia OSI ter sido apontado como a chave para a interconexo de sistemas heterogneos, alguns autores apontam certas necessidades no conseguidas pelo modelo. Svobodova [SVOB90] aponta, que apesar do modelo de referncia OSI ter sido concebido para prover uma soluo unificada para a interconexo e interoperabilidade entre sistemas e redes desenvolvidas por diferentes fabricantes existem alguns pontos no atingidos. Para Svobodova, o problema da interoperabilidade global ainda no foi solucionado. Esta situao um resultado de diversos fatores, mas o grande problema complicador a grande heterogeneidade dos ambientes endereados pelos padres. Continua mostrando que, em redes de computadores, heterogeneidade mostra trs nveis bsicos e que nem todos so abrangidos pelo modelo OSI. Os trs nveis so os seguintes: Hardware e software que formam os sistemas a serem interconectados; Meio fsico e protocolos das subredes aos quais os diferentes sistemas sero interconectados; Protocolos de alto nvel usados para a comunicao fim-a-fim entre os sistemas. Conclui, apontando que a heterogeneidade de sistemas e redes no causada somente pela incluso de mecanismos apropriados dentro do modelo OSI, mas tambm pelo aparecimento de diferentes tipos de servios e protocolos para um simples nvel.

2.2 A arquitetura TCP/IP - Transport Control Protocol / Internet Protocol

Em 1973, a Agncia de Projetos de Pesquisa Avanada 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 tcnicas de comunicao. As novas implementaes foram completadas em 1974. Em 1978, aps quatro anos de testes e refinamentos, o Departamento de Defesa norte-americano (Departament of Defense - DoD) promulgou verses de TCP/IP (Transmission Control Protocol/Internet Protocol) e obrigou o seu uso como padro do DoD. Os protocolos Internet, como mais conhecida a arquitetura TCP/IP, so projetados para redes de pacotes, que fornecem a entrega confivel de mensagens ou notificaes de falhas. Este modelo conduz ao uso de, no mnimo, dois nveis de protocolo. O primeiro nvel opera de forma fim-a-fim entre os dois hosts envolvidos em uma conversao. O segundo nvel baseado em um protocolo de baixo nvel que trabalha na forma de passar-adiante a mensagem, fazendo com que a mensagem percorra uma srie de elementos intermedirios at chegar ao destino [LEFF88]. O TCP/IP tambm pode ser dividido em camadas, assim como o modelo de referncia OSI, porm alguns autores trazem formas diferentes de representao. A seguir, na figura 2.5, est a viso de Leffler.
APLICAO TCP IP UDP ICMP

INTERFACE DE REDE

Figura 2.5 - Estruturao em camadas do TCP/IP segundo [LEFF88]. Ainda segundo Leffler, o Protocolo Internet ou IP como conhecido, um protocolo de baixo nvel e cabe a este elemento enviar a mensagem do host origem, atravs de elementos intermedirios, para o host destino. Este nvel corresponde ao Nvel de Rede do modelo OSI. O IP deve fornecer servios a nvel de rede para o endereamento do host, roteamento, e se necessrio, fragmentao e montagem dos

pacotes, caso a rede no consiga enviar a informao em um nico pacote. O Transmission Control Protocol (TCP) e o User Datagram Protocol (UDP) so protocolos do nvel de transporte que fornecem facilidades adicionais ao IP. No caso do TCP, este fornece confiana, no duplicao e fluxo de transmisso 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 no utilizado pelo usurio. Os protocolos Internet so projetados para suportar sistemas e arquiteturas heterogneas. Sistemas que usam uma variedade muito grande de representao interna de dados. Mesmo a unidade bsica de dados, o byte, no e o mesmo para todos os sistemas. Os protocolos de rede, no entanto, requerem uma representao padro, esta representao obtida atravs 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.
APLICAO TCP IP ARP UDP INTERFACE DE REDE

Figura 2.6 - Estruturao em camadas do TCP/IP segundo [CHRI91] e [COME88]. Nesta nova representao, surge mais um elemento, o ARP (Address Resolution Problem), que permite a um host encontrar um endereo fsico de um host destino na mesma rede fsica, tendo somente o endereo Internet do destino. Um sistema de comunicao dito com suporte de servios de comunicao universal se permitir que qualquer host possa se comunicar com qualquer outro host. Para se estabelecer este sistema de comunicao universal, necessrio estabelecer um mtodo de identificao de computadores aceito globalmente [COME88].

Partindo desta premissa, o endereo dos host Internet um nmero de 32 bits (4 octetos), que identifica a rede em que o host est localizado e o prprio host naquela rede. O endereo da rede atribudo por uma agncia central e o endereo do host na rede atribudo pelo administrador da rede. possvel que um host esteja ligado a vrias redes, isto implica que ele possuir mltiplos endereos. Cada host conhecido por um nmero da ARPANET IMP em cada rede em que estiver conectado e por um nmero de porto naquele IMP (Interface Message Processor). O IMP e os endereos do host ocupam um octeto do endereo. Um dos dois octetos restantes usado para designar a rede e o outro fica disponvel para ser usado como identificador de conexo multiplexada. Existem tambm algumas classes de endereos, como mostrado na figura 2.7, que so determinadas pelos bits mais significativos. As classes so 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 endereo da rede.
REDE IMP H OST LGICO ENDEREO ARPANET REDE
0 8 BITS

H OST

H OST
24 BITS

ENDEREO CLASSE A 10
16 BITS

REDE

16 BITS

HOST

ENDEREO CLASSE B REDE

24 BITS

110

H OST
8 BITS

ENDEREO CLASSE C

Figura 2.7 - Classes de endereos. Cada classe tem menos bits para a parte relativa ao endereo do host e assim suporta menos hosts que a classe mais alta. Esta forma de codificao suporta um grande nmero de redes de tamanhos variados, e mantendo ainda a compatibilidade com o antigo cdigo de endereos da ARPANET, porm, a popularidade atingida pela rede Internet est levando os seus administradores a buscarem novas alternativas de endereamento. A popularidade atingida pelo TCP/IP deve-se a cinco caractersticas essenciais

que a DARPA identificou como objetivos do projeto [SPAN88]: Confiabilidade - certamente a mais importante caracterstica do TCP/IP. O IP, como projetado, no se responsabiliza pela confiabilidade dos dados entregues, ele simplesmente garante a entrega para a rede apropriada. O TCP quem fornece a confiabilidade, atravs do mtodo full duplex e comunicao orientada a conexo entre os processos cooperantes. Interoperabilidade - esta refere-se a habilidade de sistemas de computadores diferentes comunicarem-se entre si. A interoperabilidade conseguida com trs utilitrios: FTP (File Transfer Protocol), TELNET (servio de terminal virtual) e SMTP (Simple Mail Transport Protocol). Estes utilitrios definem a interface entre o software do usurio com o software dos nveis de transporte e de rede que permite diferentes implementaes tornarem-se compatveis. Segurana - o IP inclui diversos campos dentro do cabealho que permitem uma proteo seletiva da informao. No momento do estabelecimento da conexo, as entidades devem concordar com os nveis de segurana das informaes associada para a conexo. Flexibilidade e habilidade para permitir a transio entre protocolos - o uso do TCP/IP no impe regras quanto a meios ou aplicaes para o uso. Quando o TCP/IP requer certas coisas de outros protocolos, ele utiliza primitivas que permitem a combinao. Isso se deve ao fato do TCP/IP ser heterogneo por natureza, garantindo a migrao 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 comunicaes de entrada e sada de um programa de aplicao e a tela de um terminal, ou ainda entre dois programas de aplicao. SNA consiste em um conjunto de protocolos, formatos e sequncias operacionais que controlam o fluxo de informao dentro de uma rede de comunicao de dados ligada a um mainframe IBM, micro computadores, controladoras de comunicao e terminais. A arquitetura SNA implementa um relacionamento hierrquico, tambm chamado de mestre-escravo, o que implica em que um participante de uma interao deve buscar permisso de um outro participante antes da interao ser iniciada. Redes seguindo este modelo, so menos flexveis para estabelecer relacionamentos entre entidades arbitrrias, mas so mais controlveis pelo gerente da rede [DEIT90]. Conforme o histrico relatado em [MEIJ88], a arquitetura SNA foi anunciada em 1974, porm sofreu diversas alteraes at ser o que hoje. No incio era muito limitada quanto a abrangncia e funes, mas fornecia os mecanismos bsicos necessrios para o projeto de sistemas de comunicao. As primeiras verses ficaram conhecidas como SNA 0 e 1 e fornecia apenas funes limitadas. O maior propsito era o de possuir uma arquitetura bem estruturada basicamente era constituda de um computador central (host), um ou mais controladores de canais de comunicao ligados ao host e alguns controladores de cluster, ou seja, definia trs tipos de nodos: .o nodo host; .o nodo controlador de comunicao; .o controlador de cluster. Na verso seguinte, SNA 2 tambm em 1974, algumas melhorias significativas foram introduzidas, tais como: .ligao local de controladores de cluster;

.controladores de comunicao remota; .mais um tipo nodo (Terminal); .suporte ao chaveamento de linhas de comunicao. Porm estas melhorias no ampliaram o escopo da arquitetura. Isto s ocorreu com a verso, SNA 3 - 1976, tambm conhecida por Funes de Comunicao Avanada (SNA/ACF - Advanced Communications Functions). Nesta verso eram permitidos que vrios hosts fossem interligados atravs do controlador de comunicao local. A verso SNA 4 - 1979, removia algumas restries que existiam nas verses anteriores. Uma importante melhoria do ponto de vista arquitetural foi a introduo de sesses paralelas entre hosts. Em 1982, foi anunciado um produto chamado de Comunicao Avanada de Programa a Programa (APPN - Advanced Program to Program Communication), e em 1983 foi anunciado um outro produto que garantiria a interligao de redes SNA independentes atravs de um gateway. Assim uma rede SNA passou a consistir em um ou mais domnios, onde um domnio se refere a todos os componentes fsicos e lgicos que esto conectados e so controlados por um ponto comum da rede. Este ponto comum de controle chamado de SSCP (System Services Control Point). So trs os tipos de unidades endereveis da rede (NAU - Network Address Unit) [ALVE92]: .SSCP (System Services Control Point); .PU (Physical Units); .LU (Logical Units). O SSCP consiste em um mtodo de acesso de comunicao operando em um mainframe IBM. Ele contm as tabelas de endereamento da rede, tabelas de roteamento e tabelas de traduo, que so empregadas para estabelecer conexes entre os ns da rede e controlar o fluxo de informao.

Cada domnio contm um ou mais ns, consistindo a rede SNA em um agrupamento de componentes de rede. Exemplos de ns SNA incluem os controladores de cluster, controladores de comunicaes e terminais, com o endereo de cada dispositivo na rede. Cada n SNA contm uma unidade fsica (PU), que controla os outros recursos contidos neste n. A unidade fsica (PU) no um dispositivo fsico, mas um conjunto de componentes que fornece servios usados para controlar recursos como terminais, controladoras, processadores e linhas. Ou ainda, as unidades fsicas so representaes de dispositivos e linhas de comunicao da rede [TILL90]. J o ltimo tipo de unidade enderevel da rede a unidade lgica (LU), esta serve como ponto de acesso para que os usurios possam utilizar a rede. Cada unidade fsica (PU) pode ter uma ou mais unidades lgicas, onde cada unidade lgica tem um endereo distinto. Existem os seguintes tipos de unidades fsicas: .terminais; .controladores de cluster; .processadores front-end (FEP); .hosts. Sendo que os terminais e os controladores de cluster so considerados nodos perifricos, que so aqueles que se comunicam apenas com os nodos subreas em que esto conectados. E os processadores front-end e os hosts so tipos de nodos subreas, ou seja, alm de se comunicarem com seus prprios perifricos, possuem habilidade para se comunicarem com outros nodos subreas da rede. Com respeito a estabelecimento de sesses, [KONA83] e [ALVE92], colocam que uma sesso na arquitetura SNA pode ser definida como a conexo lgica entre duas unidades endereveis da rede para troca de informao entre estas. As funes necessrias para o estabelecimento e gerenciamento destas sesses esto contidas nos vrios nveis da arquitetura da rede.

Assim como nas arquiteturas anteriores, SNA tambm dividida em camadas, alguns autores diferem quanto a sua representao hierrquica. Isto pode ser comprovado comparando a figura 2.9, que traz as vises de [SY 87] e [TILL90], com a figura 2.10, que mostra a viso de [KONA83]. SERVIO TRANSAO SERVIO APRESENTAO CONTROLE FLUXO DADOS CONTROLE TRANSMISSO CONTROLE PATH CONTROLE LIGAO CONTROLE FSICO Figura 2.9 - Representao do modelo SNA por [SY87] e [TILL90] USURIO FINAL SERVIO APRESENTAO CONTROLE FLUXO DADOS CONTROLE TRANSMISSO CONTROLE PATH CONTROLE LIGAO Figura 2.10 - Representao do modelo SNA por [KONA83]

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 escritrios 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 operao similar a do TCP/IP, tanto na estruturao quanto nos servios oferecidos, como servios orientados conexo ou no, por exemplo. Uma comparao entre a estruturao de camadas da arquitetura XNS com o modelo de referncia ISO-OSI pode ser visto na figura 2.11. Nesta representao, so apresentados vrios componentes que compem o nvel de transporte da XNS, porm, interessante observar que, no so todos os componentes que trocam informaes com os processos de usurios, isto porque alguns componentes (ECHO, RIP e ERROR) neste nvel que exercem funes prprias para manter o protocolo funcional.

APLICAO APRESENTAO SESSO TRANSPORTE REDE ENLACE FSICO Interface Hardware

ECHO RIP PEX SPP ERROR

Processos de Usurios

IDP

Figura 2.11 - Estrutura da arquitetura XNS em comparao com o modelo ISO-OSI.

Cada um dos componentes que compe a arquitetura XNS possui funes especficas, as quais so interessantes conhecer. So 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 no orientado conexes, que disponibiliza o uso de datagramas para os processos de usurios. SPP - Sequenced Packet Protocol - um protocolo orientado conexo, que permite uma confiabilidade maior que o PEX na entrega da informao, isto devido a alguns mecanismos de controle que possui. ERROR - Error Protocol - o protocolo responsvel pela descoberta dos erros ocorridos na comunicao. IDP - Internet Datagram Protocol - um protocolo no orientado conexo, que disponibiliza um servio de entrega de pacotes para todos os protocolos do nvel superior. Tanto o SPP quanto o PEX so protocolos a nvel de transporte disponibilizado na arquitetura XNS; a diferena entre ambos reside no fato de que o SPP oferece um servio orientado conexo com troca de informaes entre as partes envolvidas na comunicao de maneira confivel e full-duplex. J o PEX disponibiliza um servio no orientado conexo, com as referidas conseqncias deste tipo de servio, ou seja, no segurana da entrega das informaes e falta de confiabilidade nos dados. A representao 2.12 mostra a interao entre os processos de usurios com os protocolos do nvel de transporte, bem como a comunicao do processo de usurio diretamente com o IDP, visto que possvel. O modelo XNS foi muito bem aceito pelos usurios e desenvolvedores, tanto que modelos alternativos foram desenvolvidos tomando como referncia o modelo XNS, o caso do SPX/IPX da Novell, que apresentado a seguir. Para maiores informaes a respeito da arquitetura XNS, consultar [STEV90].

Processo de Usurio

Processo de Usurio

Processo de Usurio

SPP
(Transporte)

PEX
(Transporte)

IDP

Interface Hardware

Figura 2.12 - A comunicao entre processos de usurios 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 comunicao 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 nveis do modelo ISO-OSI. A respeito desta compatibilidade, o IPX corresponde ao protocolo de rede e o SPX ao de transporte, como mostra a representao 2.13.

APLICAO APRESENTAO SESSO SPX IPX TRANSPORTE REDE ENLACE FSICO

Figura 2.13 - Comparao da arquitetura SPX/IPX com a arquitetura ISO-OSI. A arquitetura em questo permite utilizar-se dos servios orientados e no orientados conexo, sendo que o primeiro realizado por intermdio do SPX, que garante a entrega da informao, monitorando as transmisses e retransmitindo se os respectivos reconhecimentos no retornarem; e o segundo servio realizado pelo IPX, que tm como funo enderear e rotear os pacotes aos seus destinos. A maneira como ambos atuam apresentada na figura 2.14. No caso do SPX, o processo do usurio envia e recebe informaes diretamente deste nvel (A), e este transfere as mensagens, depois de devidamente seqncializadas, para o nvel inferior (B), no caso o IPX. O simples fato de utilizar-se das funes disponibilizadas pelo SPX, com seus respectivos parmetros, garante aplicao estar utilizando o servio orientado conexo.

E caso o desenvolvedor necessite utilizar os servios no orientados a conexo, dever implementar em sua aplicao as funes que fazem acesso direto ao IPX (C). Porm, neste caso, a aplicao ficar encarregada de efetuar todo o controle para garantir a confiabilidade da informao, um vez que o IPX apenas um entregador de mensagens, no realizando controles sobre as mesmas.
Processo de Usurio A SPX B IPX C

Figura 2.14 - Fluxo da informao entre processo de usurio, SPX e IPX. Uma aplicao no fica restrita apenas a uma conexo ou ligao externa, um mesmo processo pode estar com conexes abertas com n outros processos, ou ainda despachando informaes para todos os usurios de uma rede. Esta flexibilidade pode ser vista na representao 2.15, onde um nico processo cliente pode estar se comunicando com um processo servidor qualquer atravs do SPX e mantendo contato com outros processos clientes atravs do IPX. Como nas outras arquiteturas, o SPX/IPX disponibiliza algumas funes para que os desenvolvedores de aplicaes possam utilizar seus servios. A tabela 2.3 mostra estas funes, bem como seus parmetros. As funes fazem referncia a uma estrutura de bloco de controle de eventos (ECB - Event Control Block), a estrutura de dados mais importante do protocolo, visto que armazena endereos, buffers de recepo e transmisso, alm de informaes sobre a conexo local e remota.

Processo Cliente

Processo Cliente

Processo Cliente

SPX IPX

SPX IPX

SPX IPX

IPX SPX Processo Servidor

Figura 2.15 - Comunicao entre processos clientes e servidor.

2.6 Equivalncia de servios entre as arquiteturas OSI, TCP/IP e SPX/IPX

Com base nas funes e chamadas levantadas nos itens anteriores, pde-se apontar para certas equivalncias entre os servios oferecidos pelas arquiteturas OSI, TCP/IP e SPX/IPX.

Sobre os tipos de servios, fica evidenciado que as trs arquiteturas de redes aqui mencionadas fornecem servios orientados e no orientados conexo. Algumas de maneira mais simples e outras nem tanto.

Comparaes entre as chamadas das arquiteturas podem ser vistas nesta e nas pginas que seguem.

ISO-OSI para TCP/IP

ISO-OSI
T_CONNECT_REQUEST T_CONNECT_INDICATION T_CONECT_RESPONSE T_CONNECT_CONFIRMATION T_DATA_REQUEST T_DATA_INDICATION T_EXPEDITED_DATA_REQUEST T_EXPEDITED_DATA_INDICATION T_DISCONNECT_REQUEST T_DISCONNECT_INDICATION

TCP/IP
ACTIVE OPEN sem equivalncia ACTIVE OPEN OPEN ID, OPEN SUCCESS SEND sem URGENT FLAG RECEIVE sem URGENT FLAG SEND com URGENT FLAG RECEIVE com URGENT FLAG ABORT CLOSE, TERMINATE

Tabela 2.4 - Equivalncia 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 equivalncia T_CONNECT_CONFIRMATION sem equivalncia T_DATA_REQUEST SPXSendSequencedPacket T_DATA_INDICATION SPXListenForSequencedPacket T_EXPEDITED_DATA_REQUEST sem equivalncia T_EXPEDITED_DATA_INDICATION sem equivalncia T_DISCONNECT_REQUEST sem equivalncia T_DISCONNECT_INDICATION SPXTerminateConnection Tabela 2.5 - Equivalncia do modelo ISO-OSI para SPX/IPX TCP/IP para ISO-OSI

TCP/IP
PASSIVE OPEN ACTIVE OPEN

ISO-OSI

sem equivalncia T_CONNECT_REQUEST T_CONNECT_RESPONSE SEND sem URGENT FLAG T_DATA_REQUEST SEND com URGENT FLAG T_EXPEDITED_DATA_REQUEST ALLOCATE sem equivalncia CLOSE T_DISCONNECT_INDICATION ABORT T_DISCONNECT_REQUEST STATUS sem equivalncia OPEN ID T_CONNECT_CONFIRMATION OPEN FAILURE T_DISCONNECT_INDICATION OPEN SUCCESS sem equivalncia RECEIVE sem URGENT FLAG T_DATA_INDICATION RECEIVE com URGENT FLAG T_EXPEDITED_DATA_INDICATION CLOSING sem equivalncia TERMINATE sem equivalncia STATUS RESPONSE sem equivalncia ERROR sem equivalncia Tabela 2.6 - Equivalncia 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 equivalncia ALLOCATE SPXInitialize CLOSE SPXTerminateConnection ABORT sem equivalncia STATUS sem equivalncia OPEN ID SPXOpenSocket OPEN FAILURE SPXOpenSocket OPEN SUCCESS SPXOpenSocket RECEIVE sem URGENT FLAG SPXListenForSequencedPacket RECEIVE com URGENT sem equivalncia FLAG CLOSING sem equivalncia TERMINATE SPXTerminateConnection STATUS RESPONSE sem equivalncia ERROR sem equivalncia Tabela 2.7 - Equivalncia de TCP/IP para SPX/IPX. SPX/IPX para ISO-OSI

SPX/IPX
SPXEstablishConnection SPXInitialize SPXListenForConnection SPXListenForSequencedPacket SPXSendSequencedPacket SPXTerminateConnection SPXCheckSocket SPXOpenSocket

ISO-OSI
T_CONNECT_REQUEST T_CONNECT_INDICATION sem equivalncia sem equivalncia T_DATA_INDICATION T_DATA_REQUEST T_DISCONNECT_INDICATION sem equivalncia sem equivalncia

Tabela 2.8 - Equivalncia de SPX/IPX para modelo ISO-OSI

SPX/IPX para TCP/IP

SPX/IPX
SPXEstablishConnection SPXInitialize SPXListenForConnection SPXListenForSequencedPacket SPXSendSequencedPacket SPXTerminateConnection SPXCheckSocket SPXOpenSocket

TCP/IP
ACTIVE OPEN sem equivalncia PASSIVE OPEN RECEIVE SEND TERMINATE CLOSE OPEN SUCCESS OPEN SUCCESS

Tabela 2.9 - Equivalncia de SPX/IPX para TCP/IP. interessante salientar que as equivalncias aqui levantadas so relativas aos tipos de servios que as arquiteturas fornecem e no pela sua forma de utilizao.

3 APIs - Applications Programs Interfaces

Assim como ocorre com as arquiteturas de redes, as APIs podem ser encontradas em vrios tipos, de acordo com o tipo de sistema onde se esta trabalhando. A diversidade de tipos, formas de trabalho, alm da interao, acabam por incidir diretamente na interoperabilidade entre as aplicaes, o que pode levar uma aplicao atingir um alto ou baixo grau de interoperao. Este captulo procura reunir algumas das APIs mais utilizadas, buscando identificar caractersticas operacionais dos mesmos e detectar possveis 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 fsico; 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 memria 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 usurios e sistemas de redes, alm de no necessitar mais ser implementada em hardware, podendo ser considerada como uma camada adicional de software. Seguindo a linha de produtos compatveis, o NetBIOS mantm ligao com o modelo de referncia ISO-OSI, como pode ser visto na figura 3.1. A interface de servios NetBIOS pode ser encontrada englobando os nveis de transporte e rede, ficando os nveis de aplicao, apresentao e sesso abrangidos pelo processo do

usurio e os nveis de enlace e fsico correspondendo interface de hardware. Quantos aos servios disponibilizados, podem ser encontrados os servios de nomes, sesso (servio orientado conexo), datagramas (servio no orientado conexo) e alguns comandos gerais. Existe um relacionamento entre estes tipos de servios, que pode ser observado na figura 3.2.

APLICAO APRESENTAO SESSO TRANSPORTE REDE ENLACE FSICO

Interface de Hardware Interface NetBIOS Processo do Usurio

Figura 3.1 - Relacionamento do NetBIOS com o modelo OSI.

Processo do Usurio

NetBIOS

Servios de Sesso

Servios de Nomes

Servios de Datagrama

Comandos Gerais

Interface do Hardware

Figura 3.2 - Relacionamento entre servios NetBIOS. O relacionamento no completo entre todos os servios, como pode ser visto; os comandos gerais somente se relacionam com os processos dos usurios e com a interface de hardware e o servio de nome serve como centralizador dos servios de

datagrama (no orientado conexo) e de sesso (orientado conexo). Servios de Nomes Os nomes, no NetBIOS, so usados para identificar recursos e processos, por exemplo, um processo cliente identifica um processo servidor especfico por um nome do servidor e o servidor pode determinar para que deve enviar as informaes atravs 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 vrios elementos da rede. Os comandos utilizados para manipular estes nomes so aqueles apresentados na tabela 3.1. ADD_NAME ADD_GROUP_NAME DELETE_NAME Adiciona um nome nico Adiciona um nome de grupo Elimina um nome (nico ou de grupo)

FIND_NAME Encontra um nome, se existir Tabela 3.1 - Comandos do servio de nomes. Servios de Sesso Estes servios fornecem ao NetBIOS servios orientados conexo, com confiabilidade e com caractersticas full duplex. Os dados so armazenados dentro de mensagens e cada mensagem pode ter entre 0 e 131.071 bytes. Seus comandos podem ser vistos na tabela 3.2. Servios de datagrama NetBIOS suporta servios no orientados conexo, com datagramas de at 512 bytes, e como os demais equivalentes, no oferece garantias quanto a confiabilidade dos dados transmitidos. CALL LISTEN SEND SEND_NO_ACK RECEIVE RECEIVE_ANY Solicita uma conexo - active open. Aguarda solicitao de conexo - passive open. Envia dados da sesso. Envia dados da sesso sem reconhecimento. Recebe dados da sesso. Recebe dados da sesso vindos de qualquer cliente.

HANG_UP SESSION_STATUS

Encerra sesso. Mostra status da sesso.

Tabela 3.2 - Comandos do servio de sesso. Os datagramas podem ser enviados para um nome especfico (nico), para grupos, ou ainda, para todos os nomes da rede. Os comandos usados para trabalhar com esta modalidade so mostrados na tabela 3.3. SEND_DATAGRAM SEND_BROADCAST_DATAGRAM RECEIVE_DATAGRAM Envia datagramas. Envia datagramas na forma broadcast. Recebe datagramas.

RECEIVE_BROADCAST_DATAGRAM Recebe datagramas na forma broadcast. Tabela 3.3 - Comandos do servio de datagrama. Comandos Gerais So comandos que no se enquadram nas especificaes anteriores. RESET CANCEL ADAPTER_STATUS UNLINK Reinicializa o NetBIOS. Cancela um comando. Busca o status da placa. Elimina a ligao com o bootstrap do servidor (para estaes diskless). Tabela 3.4 - Comandos gerais. O fato do NetBIOS no necessitar mais ser implementado no hardware da rede faz com que ele volte a ser utilizado muito hoje em dia, principalmente em aplicaes que trabalhem no esquema ponto-a-ponto.

3.2 O mecanismo RPC - Remote Procedure Call

Apesar da maioria dos sistemas possurem formas para a sua interligao, eles no 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 utilizao. Sugere-se, portanto, a utilizao da chamada remota de procedimento para suprir esta falta de padronizao 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 endereos prprios, no permitindo o conceito de variveis globais como acontece em procedimentos normais dentro de processos locais.
Processo Comunic. Local
Comunicao

Processo Comunic. Local

Remota

Processo

Processo

HOST B

HOST A

Figura 3.3 - Comunicao local e remota entre processos. Em muitos sistemas, tanto o cliente como servidor esto dentro de um mesmo processo em um determinado sistema e existe uma ligao lgica entre eles. Esta modalidade de chamada recebe o nome de chamada local de procedimento. Porm, 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 to simples como as chamadas locais de procedimento. Para tanto, alguns

pontos devem ser levados em considerao, tais como: Passagem de parmetros - A passagem de parmetros entre cliente e servidor pode no ser transparente, visto que existem problemas para se passar parmetros por referncia. A maioria dos autores sugerem a passagem apenas de parmetros por valores. Conexo (BINDING) - Consiste na conexo 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. Manipulao de erros - Com um procedimento local h um nmero limitado de coisas que podem dar errado, porm 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. Representao dos dados - Quando se utiliza uma chamada local, tanto o cliente como o servidor esto executando em um mesmo sistema, portanto, no existem problemas de compatibilidade de dados, porm, isto pode no acontece quando se utiliza RPC, pois o cliente e o servidor podem estar em arquiteturas distintas, e isso acarretar na necessidade de converso dos dados. Desempenho - Normalmente o desempenho da chamada remota menor se comparada com a chamada local, porm RPC deve ser vista como uma forma de utilizar procedimentos de outros sistemas e no 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 servios de transporte universal, suportando os mais variados servios de transporte. Esta interface compem-se, basicamente, por duas partes: a primeira est baseada no equipamento cliente que necessitar mapear suas solicitaes ou servios para um protocolo diferente daquele que possui em seu equipamento; j a segunda parte reside nos equipamentos servidores - figura 3.4, os quais disponibilizaro seus servios aos clientes .
Servidor TCP/IP

Rede A Cliente

Sub Sistem a de Com unicao

Servidor O SI

Rede B Cliente

Rede C Cliente Servidor SPX/IPX

Figura 3.4 - Representao da arquitetura utilizada pela interface C & S. A maneira como a interface atua relativamente simples e pode ser compreendida tomando como referncia a figura 3.5. Seu funcionamento consiste em uma aplicao qualquer, desenvolvida em um equipamento cliente, necessitar utilizar servios de um protocolo que no o disponvel em seu equipamento, ou ento, ter acesso a uma rede que utiliza um

protocolo diferente daquele encontrado em seu ambiente. A soluo 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. Aps esta alterao, executa-se a aplicao e, as chamadas introduzidas redirecionam a parte dependente de protocolo para um mdulo da interface residente no equipamento cliente, e este envia, na forma de mensagem, a informao para o servidor daquele protocolo desejado e este pode processar a solicitao ou transferir para uma outra rede. A figura 3.5 demonstra o fluxo das aes descritas anteriormente.
Cliente Servidor

Aplicao Cliente

Aplicao Servidora

Mdulo C&S Cliente

Sub Sistema de Comunicao

Mdulo C&S Servidor

Figura 3.5 - Comunicao entre a aplicao cliente com a aplicao servidora. A interface C & S implementa uma comunicao entre processos - processo cliente e processo servidor, no caso - onde a parte dependente de protocolo passada como uma mensagem entre os processos envolvidos na comunicao. O protocolo que gerncia esta troca de informao recebe o nome de IPCS (InterProcess Clean and Simple) [COLE87]. A representao 3.6 mostra como efetuada a troca de mensagens utilizando as primitivas write e read como exemplos.

C lien te

IP C S
W rite(arte_ d ep _ p ro to co l ) p R ea dp( arte_ d ep _ p ro to co l )

S erv id o r

Figura 3.6 - Representao do IPCS. A interface C & S disponibiliza ao implementador uma variedade de primitivas. Tais primitivas podem ser observadas na tabela 3.5. Primitivas getid Funes Retorna um handle que usado nas primitivas seguintes. O handle pode ser usado para interromper as primitvas open ou listen, caso seja necessrio. Dado um endereo destino como parmetro, feita uma tentativa para abrir uma chamada. Usa um endereo opcional, espera por uma requisio de chamada. Copia dados disponveis na entrada para o buffer do usurio. Envia dados de um buffer do usurio para a conexo. Executa um encerramento controlado na conexo. Fecha imediatamente a conexo e inicializa todos os recursos. Causa uma reinicializao na conexo. Tabela 3.5 - Primitivas da interface C & S. Caso o desenvolvedor ou usurio utilize esta interface para alterar sua aplicao, este dever, de posse do cdigo-fonte da mesma, identificar todas as partes dependentes de protocolo desejado e no disponibilizado no equipamento e adicionar junto elas as respectivas primitivas oferecidas pela interface C & S, a fim de garantir a comunicao com o servidor do protocolo pretendido.

open listen read write close abort reset

3.4 O mecanismo Socket

Sockets so mecanismos de comunicao entre processos implementados no sistema UNIX 4.3BSD e que permite a comunicao entre processos dentro de um mesmo domnio e tambm com processos em execuo em sistemas remotos. Seu surgimento deu-se com o sistema 4.1cBSD em 1982 e ela vm sendo aprimorada com o aparecimento de novas verses. A interface socket fornece canais de comunicao full duplex e atua como um elemento que recebe as chamadas vindas do processo do usurio e transmite-as ao protocolo de comunicao e este, por sua vez, se encarrega de despacha-la para os nveis inferiores - interface de rede e meio fsico - como pode ser observado na figura 3.7.

Processo do Usurio

Interface de Chamadas do Sistema de Sockets

Kernel

Protocolo de Comunicao (TCP, UDP e outros)

Data Link Device Driver (Ethernet)

Figura 3.7 - Representao da Interface Socket em um sistema. Na verdade, no existem conexes fsicas estabelecidas entre os pontos que se comunicam, mas somente conexes virtuais, uma vez que os sockets implementam pontos de conexes abstratos que apenas existem durante a comunicao, ou seja, so

criados e destrudos dinamicamente. Sockets disponibilizam aos usurios seus servios atravs de chamadas de sistema que devem ser adicionadas s aplicaes para que possam efetuar a troca de informao com outros processos, locais ou remotos. A interface sockets permite ao usurio desenvolver aplicaes que utilizem os servios orientados conexo e no orientados conexo. 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 servio desejado, deve-se utilizar certas chamadas em detrimento de outras. As figuras 3.8 e 3.9 mostram como se realiza a conversao entre os processos envolvidos, bem como as chamadas que devem ser utilizadas.

S er v id o r

so c k e t() C lie n te b in d () s o ck e t()

re c v fr o m () B lo q u e a d o a t r ec eb e r d a d o s d o c lien te D a d o s (R eq u isi o ) R e q u is i o d o p ro c e ss o D a d o s (R e sp o sta )

b in d ()

se n d to ()

se n d to ()

re cv fr o m ()

Figura 3.8 - Sockets usando servio no orientado conexo.

Servidor
socket()

bind()

listen()

Cliente
accept() Bloqueado at receber conexo do cliente Estabelecimento de C onexo connect() socket()

read() Requisio do processo

D ados (R equisio)

write()

write()

D ados (R esposta)

read()

Figura 3.9 - Sockets usando servio orientado conexo. interessante complementar que socket abre uma real possibilidade de se atingir a interoperabilidade entre aplicaes em ambientes distintos, principalmente se as aplicaes envolvidas fizerem uso da arquitetura TCP/IP. Os fatores que apontam para este sucesso so a ceitao das duas tecnologias serem bem aceitas pela comunidade de desenvolvedores e conseguirem facilmente interoperarem-se. A facilidade da interoperao entre sockets e TCP/IP deve-se ao fato deste ltimo implementar a tcnica de porto, que por sua vez utilizada pelos sockets. Um mesmo porto consegue gerenciar mltiplos sockets e isso permite que vrias

aplicaes estabeleam conexes simultneas com o mesmo porto. Davidson mostra, em [DAVI92], que alguns portos tm seus endereos, ou nmeros, pr definidos e que um socket composto por um endereo IP e um porto. Sendo assim, alguns servios bsicos podem estar associados a determinados portos e quando a aplicao desejar fazer uso deles, basta conetar-se ao respectivo porto. A figura abaixo mostra dois sockets conectando-se a um porto TCP para utlizarem-se do servio disponibilizado.
Socket 132.151.1.4,1055 Conexo o o o Socket 132.151.1.12,2111 Socket 132.151.11.1,23 (End. IP, porto) Servidor TELNET Servidor TELNET

Figura 3.10 - Sockets utilizando portos para conexo TCP/IP. Na representao 3.10, pode-se observar que o porto 23 esta gerenciando duas conexes, sendo que estas duas conexes esto fazendo uso do servio de comunicao TELNET. A facilidade de se estabelecer comunicao entre aplicaes que fazem uso do socket e aplicaes que fazem uso do TCP/IP, abre grandes horizontes para se atingir a interoperabilidade, visto que a aplicao socket, baseada em TCP/IP pode interagirse com qualquer aplicao que esteja utilizando TCP/IP, independente do tipo de plataforma ou sistema operacional que se esteja utilizando. Maiores informaes 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 verso 3.0 do UNIX System V em 1986, com a inteno de fornecer aos desenvolvedores uma interface a nvel de transporte baseado no modelo ISO-OSI. Consiste em um conjunto de funes e pode ser dividida em duas partes, a biblioteca TLI e o mdulo TLI. A biblioteca TLI composta pelas funes propriamente ditas, que so disponibilizadas aos usurios e desenvolvedores, para que estes incorporem-as em suas aplicaes e o mdulo TLI responsvel pela adequao das funes camada de transporte disponvel no ambiente. Ela to flexvel que permite aos desenvolvedores escrever aplicaes sem se preocuparem com o tipo de transporte que se est utilizando [DAVI92]. interessante realar que a TLI, biblioteca e mdulo, no 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 aplicao usando as funes da biblioteca em questo sobre uma camada SPX, poder levar esta mesma aplicao para um ambiente OSI ou TCP/IP sem ter que rescrever o cdigo, bastando recompil-la no ambiente desejado. Esta flexibilidade garantida pelo mdulo TLI que ao detectar uma funo da biblioteca converte o formato da mensagem para o tipo de transporte disponvel. Esta vantagem importantssima para se atingir a interoperabilidade entre aplicaes. A figura 3.11 traz o relacionamento da biblioteca TLI com o mdulo TLI, juntamente com a aplicao e outras partes envolvidas no processo. V-se no topo da estrutura o mdulo correspondente aplicao do usurio incorporando a biblioteca TLI, uma vez que tal aplicao efetua chamadas da referida biblioteca. A seguir encontra-se stream head, que executa a converso do formato da informao para uma forma entendida pelo nvel inferior (mdulo TLI).

Aplicao Biblioteca TLI

Stream Head

Mdulo TLI

Mdulo Transporte

Mdulo Rede

Device Drivers

Figura 3.11 - Relacionamento da biblioteca TLI com o mdulo TLI.

O mdulo TLI atua como um conversor do formato da mensagem vinda do nvel superior para o mdulo de transporte que se est utilizando naquele momento. J os mdulos de transporte, de rede e os device drivers tm a sua atuao normalmente, gerenciando conexes, efetuando checagens e correes, enfim, as tarefas que lhes so atribudas.

Dentre as funes que so disponibilizadas pela TLI, podem ser encontradas aquelas que permitem o uso de servios orientados conexao e aquelas para serem utilizadas em servios no orientados conexo. Isto ocorre pelo fato da TLI, assim com o TCP/IP e SPX/IPX, tambm disponibilizar estes tipos de servios, uma vez que o modelo ISO-OSI tambm o faz.

Como mencionado anteriormente, a TLI permite a utilizao dos servios

orientados e no orientados conexo. As figuras 3.12 e 3.13 demonstram quais as funes que so utilizadas em cada caso, bem como a seqncia das mesmas.

O nico aspecto complicador em utilizar-se da TLI reside no fato de que, se o usurio possuir aplicaes e desejar utilizar-se da facilidades desta biblioteca, dever trocar as instrues de sua aplicao pelas funes TLI correspondentes, ou ento rescrever suas aplicaes usando agora as novas funes.
Servidor
t_open()

t_bind()

Cliente
t_open()

t_alloc)

t_bind() t_listen() Bloqueado at receber conexo do cliente Estabelecimento de C onexo

t_alloc()

t_accept()

t_connect()

t_rcv() R equisio do processo

D ados (R equisio)

t_snd()

D ados (R esposta) t_snd() t_rcv()

Figura 3.12 - Funes TLI para servio orientado conexo.

Servidor
t_open()

Cliente
t_bind() t_open()

t_alloc()

t_bind()

rcvudata() Bloqueado at receber dados do cliente Requisio do processo

t_alloc()

Dados (Requisio)

t_sndudata()

t_sndudata() Dados (Resposta)

t_rcvudata()

Figura 3.13- Funes TLI para servio no orientado conexo.

4 Interoperabilidade e Interconectividade de sistemas

As dificuldades encontradas para se atingir a interconectividade e interoperabilidade residem em adotar-se um padro. Infelizmente, os esforos em se seguir padres imparciais sugeridos por orgo internacionais no tm dado certo, visto que as definies oferecidas por estes orgos as vezes no coincidem com as necessidades ou aspiraes do mercado; vide a tradicional disputa ISO-OSI com TCP/IP. No tocante a interconectividade, no existem tantos problemas, uma vez que a comunidade de usurios e desenvolvedores parecem ter chegado a padres mais estticos, utlizando Ethernet, Token Ring, ArcNet entre outros, com suas respectivas topologias para efetuar a interligao entre os elementos envolvidos no processo de comunicao. Caso o interessado deseje interconectar ambientes de mesmo padro, ele pode fazer isto por intermdio de uma ponte e caso deseje interconectar ambientes com padres diferentes pode utilizar-se de um gateway, conforme representao 4.1.

Lan Ethernet

Ponte

Lan Ethernet

Gateway Lan Ethernet Lan Token Ring

Figura 4.1 - Representao de uma ponte e um gateway. No caso de uma ponte, a informao vinda de uma rede simplesmente

transferida para a outra rede, sem que exista a preocupao de alguma espcie de transformao no formato dos pacotes. Esta mesma facilidade no se obtm na utilizao do gateway, uma vez que os pacotes devero ter seus formatos alterados para o tipo correspondente ao da rede destinatria. Porm, se houver a necessidade de quaisquer mudanas, elas sero feitas pelos prprios equipamentos envolvidos na operao, no caso, o gateway e a ponte, no preocupando o usurio no que tange a sua aplicao. Esta mesma transparncia no encontrada na interoperabilidade. A interoperabilidade utiliza a interconectividade, atuando a nvel de software, portanto, cabe ao usurio observar e tratar as incompatibilidades entre as partes envolvidas. Uma prova de que as dificuldades em se atingir a interoperao so muitas e de que os padres tambm, 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 padro OSI, TCP/IP, SPX/IPX entre outros. Onde encontram-se uma compatibilidade a nvel de servios oferecidos, mas no a nvel de formato das chamadas, conforme pode ser constatado no captulo Arquiteturas. Dentre as maiores dificuldades que os desenvolvedores encontram para atingir a interoperabilidade, podem ser destacadas a maneira como as aplicaes envolvidas efetuaro a troca de informao, qual o formato da informao, qual o protocolo envolvido na operao, a portabilidade de uma aplicao para um outro ambiente distinto entre tantas outras. Diante deste amontoado de dificuldades, os desenvolvedores tm colocado seus conhecimentos para prover mecanismos que permitam superar estes obstculos. Alguns exemplos destes mecanismos podem ser encontrados na literatura e mesmo em projetos prticos. o caso, por exemplo, de se construir aplicaes gateways responsveis por receber, converter e despachar a informao, como sugere [ROSE90] e muitos outros autores, ou ento de se construrem primitivas que direcionam a parte dependente de protocolo da aplicao para elementos dedicados a determinados servios de converso, como acontece na interface Clean and Simple [COLE87], adoo de filtros conversores para as aplicaes, ou ainda de se criar funes universais, que independem do tipo de protocolo e formato da informao que sero utilizados, como

mostra [STEV90] sobre a TLI. Enfim, existem uma srie de mecanismos que buscam atingir a interoperao, alguns conseguindo um maior grau e outros nem tanto, mas todos buscando atingir seus objetivos. No caso da utilizao das aplicaes gateways, a aplicao original no ser alterada, em conseqncia, existir um mdulo extra, ou um processo, encarregado de receber as chamadas feitas pela aplicao, efetuar a alterao e despachar para o processo destino; alm claro de executar o processo inverso no caso de recebimento de informaes, figura 4.2. Estas aes podem comprometer o desempenho da aplicao, e em situaes crticas, como processamento em tempo real por exemplo, podem comprometer a estabilidade do sistema.

A plicao A plicao

A plicao G atew ay

H ST A O

H ST B O

Figura 4.2 - Utilizao da tcnica Aplicao Gateway. Quanto interface Clean and Simple (C & S), o usurio dever alterar o cdigo fonte da aplicao, adicionando as primitivas que a interface disponibiliza. Aps esta atividade, necessita-se recompilar a aplicao e eleger alguns computadores para serem os servidores de protocolos, que sero encarregados de receberem as solicitaes, process-las e despacha-las s redes destinatrias. Aqui o desempenho tambm pode ser afetado, visto que a comunicao no direta entre as partes envolvidas, mas sim atravs de um elemento intermedirio. A forma de funcionamento da C & S, bem como outros detalhes, podem ser obtidos no captulo APIs.

Os filtros aparecem como uma boa opo. Eles tomam o cdigo fonte da aplicao, analisam, e efetuam as alteraes que forem necessrias. O usurio, por sua vez, recompila a aplicao e esta passa a comunicar-se diretamente com o ponto desejado; sem ter que trafegar por um elemento intermedirio. O desempenho, na utilizao dos filtros, estaria garantido, porm o fator complicador nesta situao est em se conseguir filtros que convertam as aplicaes de forma completa, caso contrrio, o usurio dever interferir no novo cdigo fonte gerado e adequa-lo as suas reais necessidades.
Aplicao A Nova Aplicao A

FILTRO

Aplicao B

Comunicao

Nova Aplicao A

HOST B

HOST A

Figura 4.3 - Utilizao da tcnica de filtro. Uma outra alternativa a utilizao da TLI, que oferece um conjunto de funes que no esto ligadas diretamente a um protocolo; so funes universais que podem ser mapeadas para todos os protocolos suportados pela TLI. O desempenho fica garantido mas o usurio dever escrever novamente todas as suas aplicaes, trocando as partes dependentes de protocolo pelas funes TLI. Veja captulo sobre API. Fica comprovado ento que, apesar de existirem tcnicas para se buscar a interoperabilidade, estas no so completas; se elas no pecam pelo desempenho, pecam pelo trabalho extra atribudo ao usurio ou vice-versa. Conseqentemente, no existe a melhor tcnica, mas sim, a melhor tcnica para cada caso, que deve ser analisado previamente, considerando todas as

necessidades e implicaes.

Texto gentilmente cedido por Flvio Toledo (flaviot@sti.com.br)

www.sti.com.br