You are on page 1of 30

POSIG

PERFIL OSI DO GOVERNO BRASILEIRO

Mauricio A. Lyra

Escrito em 05/08/1992
Revisto e reformatado em 23/03/2004
POSIG
PERFIL OSI DO GOVERNO BRASILEIRO

OBJETIVOS DESTE TRABALHO


• Posicionamento dos Produtos IBM® ®
• Arquitetura de Referência
• Esclarecimentos Importantes

PREFÁCIO
Esta publicação enfoca o Decreto Presidencial No 518, de 8 de maio de
1992, que dispõe sobre a adoção do Modelo de Referência OSI1 pela Admi-
nistração Pública Federal.
São analisados o Decreto, seu anexo, instruções normativas, as versões atual
e futuras do POSIG - Perfil OSI do Governo Brasileiro e a aderência dos
produtos OSI da IBM®® às recomendações do POSIG. Antes, porém, da-
mos uma visão geral do que é o OSI e comentamos outros aspectos gerais a
ele relacionados.
Com isso pretendemos fornecer ao leitor importantes informações que são
necessárias no relacionamento diário com este palpitante assunto.

1
OSI - Open Systems Interconnection

2
A Arquitetura OSI

As Arquiteturas
Não é de hoje que os fabricantes de computadores perceberam a necessidade de definir suas próprias
arquiteturas de rede.
Mas o que é uma arquitetura? Eis a definição genérica para arquitetura:
“Uma arquitetura é um conjunto de regras que governam a conexão e a interação dos
vários componentes de um sistema”.
Todo sistema tem uma arquitetura que dita as regras para o inter-relacionamento dos diversos blocos
ou componentes que o compõem.
São exemplos de sistemas: uma casa, um avião, uma empresa, um computador (e o seu “hardware” e
o seu “software”).
Quando se fala de comunicações de dados, logo pensamos em sistemas com um sem número de
componentes, como por exemplo:
• Componentes Físicos - computadores, terminais, modems, linhas de comunicações - é o
“hardware”.
• Componentes Lógicos - sistemas operacionais, sistemas de arquivos, programas de controle,
programas de aplicação - é o “software”.

É importante haver um conjunto de regras que ditem como esses componentes devem interagir e co-
mo são suas interfaces comuns. A este conjunto de regras e interfaces damos o nome de Arquitetu-
ra de Rede.
Uma arquitetura de rede é uma “solução completa” para a interconexão de sistemas. Ela compreen-
de:
• Um conjunto completo de regras para governar a conexão e a interação entre os componentes
de sistemas distribuídos de computação que desejam se comunicar.
Estas regras, denominadas protocolos, cobrem as conexões físicas e lógicas que são necessá-
rias para prover os serviços necessários.
• As especificações que detalham a provisão e a utilização dos serviços disponíveis.

É bom deixar claro que uma arquitetura de rede não é:


• Uma organização de sistema específica ou fechada
• Uma especificação interna de produto
• Um determinado nível de software de aplicação

3
As Camadas
As arquiteturas de rede são geralmente estruturadas em camadas, onde as camadas mais baixas pres-
tam serviços para as camadas mais altas. Cada uma dessas camadas é, na realidade, a representação
simbólica de um determinado subconjunto de protocolos e serviços da arquitetura. Monta-se, assim,
uma estrutura modular, bem definida e fácil de manter. Dentre as vantagens de uma estrutura em
camadas podemos destacar:
• Os serviços envolvidos podem ser separados em pequenas unidades facilmente gerenciadas.
Isto vai manter a estrutura e as interfaces da rede tão simples quanto possível.
• As funções podem ser independentes uma das outras. As pessoas responsáveis pelo desen-
volvimento dos sistemas podem ser melhor distribuídas pelos diversos departamentos com
responsabilidade por este trabalho.
• Os protocolos e regras podem ser estabelecidos dentro de cada camada e são únicos e apro-
priados para a operação da camada.
• Como as camadas são independentes em termos de funções, é possível fazer modificações
e/ou adições em uma camada sem afetar as outras.
• As camadas são representadas em pilhas, a camada 1 (a de mais baixo nível) na parte de bai-
xo da pilha. Esta camada fornece os serviços para a interface física com os meios de comuni-
cação. Na fase de projeto, as camadas são desenhadas de tal forma que, à medida que se sobe
na pilha, cada camada adiciona valores às funções e serviços providos pelas camadas de bai-
xo, até que todas as necessidades dos programas de aplicação tenham sido alcançadas. A ca-
mada mais alta fornece justamente os serviços voltados para as interfaces com os aplicativos.

O OSI
Utilizando as vantagens das estruturas em camadas, surgiram diversas arquiteturas de rede, cada uma
desenvolvida por um diferente fabricante de computador. Dentre elas destacamos a Arquitetura
SNA2, da IBM®®, cujos primeiros produtos foram colocados à disposição dos nossos clientes nos
primeiros anos da década de 70. Essas arquiteturas são comumente chamadas de “arquiteturas pro-
prietárias” em virtude de contemplarem, na maioria das vezes, tão somente as implementações
(“hardware”, “software” e interoperabilidade) dos fabricantes que as desenvolveram.
Em 1977 foi outorgada à ISO3 a função de formular um modelo de referência que promovesse uma
base comum para o desenvolvimento de padrões, de modo a permitir a interconexão e a interoperabi-
lidade universal entre as implementações dos diferentes fornecedores. O modelo resultante foi de-
nominado de Modelo de Referência da ISO para a Inteconexão de Sistemas Abertos, ou mais
simplesmente, OSI - Open Systems Interconnection.
A descrição desse modelo o define como aberto (“open”), na medida em que ele não se preocupa
com as:
• aplicações específicas de cada fabricante,
• redes particulares de computadores,

2
SNA - Systems Network Architecture
3
ISO - International Standards Organization

4
• comunicações dentro dos sistemas individuais.

O OSI só diz respeito à formação de uma estrutura em camadas com as definições dos protocolos de
comunicações, de modo a permitir a troca de informação entre sistemas cooperativos, para uma
extensa faixa de aplicações.
São as seguintes as sete camadas da arquitetura OSI:

Camada Nome (em inglês) Nome (em português)


7 Application Aplicação
6 Presentation Apresentação
5 Session Sessão
4 Transport Transporte
3 Network Rede
2 Data Link Enlace
1 Physical Física

Nessa estrutura em camadas, as mais baixas são as que definem as interfaces com as redes de comu-
nicação, enquanto que as camadas de mais alto nível estão voltadas para as interfaces que dizem res-
peito aos processos aplicativos para atender aos usuários finais.

Os Padrões (“Standards”)
O que seria um padrão? Um padrão é “uma especificação técnica ou outro documento disponí-
vel para o público, desenhada com a cooperação e o consenso ou a aprovação geral de todos os
interessados afetados por ela, baseada nos resultados consolidados da ciência, tecnologia e ex-
periência, visando à promoção de ótimos benefícios para a comunidade, e aprovada por um
órgão reconhecido a nível nacional, regional ou internacional”. Esta é a definição formal da ISO.
Não nos espantemos com a existência de padrões. Eles já nos são familiares há muito tempo. São os
padrões para a segurança elétrica, para a construção de edifícios e para as comunicações telefônicas.
Já imaginou que seria quase impossível falar por telefone com alguém em outra cidade ou outro país
se não houvesse uma padronização dos equipamentos e/ou interfaces elétricas que regem este tipo de
comunicação?

As Organizações Padronizadoras
Muito mais do que confusos nomes representados por siglas, as diversas organizações padronizado-
ras existentes pelo mundo dedicam-se ao minucioso trabalho de preparar os padrões a serem adota-
dos em âmbito regional ou mundial. Na área da comunicação de dados as duas principais organiza-
ções internacionais são:
• International Standards Organization (ISO), e
• Comité Consultif International de Télégraphie et Téléphonie (CCITT).

5
A ISO é parte da Organização das Nações Unidas (ONU). Seus membros são os órgãos nacionais de
padronização. A ISO é a responsável por todo o tipo de padrão internacional, exceto nas áreas de
equipamentos elétricos e eletrônicos. Ela está organizada em diversos comitês técnicos, cada um
responsável por uma área particular de padronização.
O CCITT é parte da ITU4, um dos órgãos da ONU. Seus membros são os governos membros da
ONU. Na prática, suas atividades são dirigidas pelos órgãos governamentais de cada país, responsá-
veis pelas áreas de Correio, Telegrafia e Telefonia.
Além dessas duas, existem diversas outras organizações envolvidas com padrões, tanto em âmbito
nacional como internacional. Dentre elas podemos destacar:
• Organizações Internacionais
• CEN - Comité Europeen de Normalisation,
• CENELEC - Comité Europeen de Normalisation Electrotechnique,
• CEPT - Conference Europeene des Administrations des Postes et des Telecomunications,
• ECMA - European Computer Manufacturer’s Association,
• IEC - International Electrotechnical Commission (da ONU).

• Organizações Nacionais
• ABNT - Associação Brasileira de Normas Técnicas (Brasil),
• AFNOR - Association Française de Normalisation (França),
• ANSI - American National Standards Institute (USA),
• BSI - British Standards Institute (Inglaterra),
• DIN - Deutsches Institut fur Normung e.V. (Alemanha),
• INTAP - Interoperability Technology Association for Information Processing (Japão).

• Organizações Profissionais
• EIA - Electronic Industries Association (USA),
• IEEE - Institute of Electrical and Electronic Engineers (USA).

Padrões Internacionais
Essas e outras organizações que existem pelo mundo, de uma forma ou de outra, direta ou indireta-
mente, fazem presença no JTC15. O JTC1 é o comitê, formado pela ISO e pela IEC, responsável
pelo desenvolvimento da arquitetura OSI através de seus diversos subcomitês.

4
ITU - International Telecommunications Union
5
JTC1 - Joint Technical Comittee 1

6
Esses subcomitês estudam e desenvolvem os padrões OSI, passando por diversas etapas. Primeiro é
preparado o “Draft Proposal - DP”, depois o “Draft International Standard - DIS” e, finalmente, o
“International Standard - IS”. É um processo que pode consumir vários anos de trabalho.
Já o CCITT desenvolve e publica “recomendações”, ao invés de padrões, relacionadas à telefonia,
fac-símile e telefonia. Embora não sejam “padrões”, na acepção que se confere aos padrões da ISO,
essas recomendações são aceitas como se o fossem.
O processo de trabalho do CCITT é diferente da ISO. Sua programação está dividida em períodos de
estudos de quatro anos, cada um começando e terminando com uma sessão plenária. Dessa forma, de
quatro em quatro anos são publicadas novas recomendações e/ou revistas as anteriormente publica-
das em livros coloridos:
• 1980 - Yellow Book (Livro Amarelo),
• 1984 - Red Book (Livro Vermelho),
• 1988 - Blue Book (Livro Azul),
• 1992 - White Book (Livro Branco).

A partir de 1992 o CCITT não mais realizará as costumeiras revisões quadrienais em todas as suas
recomendações: o “White Book” será a última edição. De agora em diante as eventuais alterações nas
recomendações já publicadas, e mesmo as novas recomendações, poderão ser liberadas a qualquer
momento, sem intervalos de tempo pré-fixados.
Dentre os padrões internacionais (International Standadards - IS) OSI e recomendações do CCITT
hoje existentes, podemos destacar:
• X.25 - Recomendação de transporte para as camadas mais baixas do OSI. Definida em 1976
e revista em 1980, 1984, 1988 e 1992,
• X.400 - Recomendação para Correio Eletrônico (“MHS – Message Handling System”), apli-
cativo para a camada mais alta do OSI. Definida em 1984 e revista em 1988 e 1992,
• FTAM6 - Padrão para a transferência e gerência de arquivos, aplicativo para a camada mais
alta do OSI. Definido em 1988,
• X.500 - Recomendação para diretórios. Definida em 1988 e revista em 1992,
• VT7 - Padrão para terminal virtual,
• Token-Ring - Padrão para método de acesso ao meio físico, para redes locais. Definido em
1990,
• Ethernet - Padrão para método de acesso ao meio físico, para redes locais. Definido em 1990,
• Gerenciamento - Diversos padrões, disponíveis a partir de 1991. Alguns ainda são DIS,
• TP8 - Será IS até o final de 1992.

6
FTAM - File Transfer Access Management
7
VT - Virtual Terminal
8
TP - Transaction Processing

7
Perfis Governamentais
Os governos de diversos países têm se preocupado com a adoção do padrão OSI em seus parques de
processamento de dados. Isto se deve principalmente ao fato de que eles são grandes clientes, tem as
mais diversas e complexas necessidades, e acumularam ao longo dos anos um sem número de im-
plementações variadas, de diferentes fornecedores, e que cada vez mais precisam se inter-relacionar.
Os governos americano e inglês, por exemplo, divulgaram os documentos denominados GOSIP -
Government Open Systems Interconnection Profile. Neles estão definidos os conjuntos de regras
para comunicações que permitem que os sistemas desenvolvidos por diferentes fornecedores possam
interoperar, possibilitando que os usuários de diferentes aplicações nestes sistemas troquem informa-
ções entre eles.
Esses documentos definem perfis e protocolos que aderem ao modelo OSI e regulamentam as com-
pras de equipamentos por parte daqueles governos. Só podem ser adquiridos pelos seus órgãos go-
vernamentais os sistemas de rede e comunicações (além de serviços) que estejam de acordo com os
GOSIPs. Estes, em suma, objetivam:
• Alcançar conectividade e interoperabilidade entre múltiplos fornecedores,
• Reduzir os custos do governo através do uso de “hardware”, “software” e serviços de forne-
cedores alternativos,
• Usar tecnologia avançada,
• Estimular o aparecimento de produtos OSI comerciais.

O GOSIP americano (US GOSIP) teve sua versão 1 tornada obrigatória em 15/08/1990, e a versão 2
em agosto de 1991. Novas versões serão publicadas de tempos em tempos, adicionando novos pro-
tocolos e funções. Este ciclo deverá ser de 18 a 24 meses. A versão 3 será obrigatória a partir de
agosto de 1993.

POSIG
O Governo do Brasil também publicou as suas referências aderentes ao modelo OSI, o POSIG - Per-
fil OSI do Governo Brasileiro, motivo principal desta publicação.
Importante: A pronúncia correta é “PÓSIG”.

Os próximos capítulos cobrem assuntos relativos ao POSIG.

8
POSIG: O Decreto No. 518

O Decreto Presidencial No 518 foi publicado em 8 de maio de 1992 no Diário Oficial da União e dis-
põe sobre a adoção do Modelo de Referência OSI pela Administração Pública Federal.

Abrangência
É a mais ampla possível. Inclui:
• Órgãos e entidades da Administração Pública Federal direta e indireta,
• Fundações instituídas ou mantidas pelo Poder Público,
• Demais organizações sob o controle direto ou indireto da União.

Efetividade
Estabelece o Decreto que, ao serem adquiridos bens e serviços de informática para comunicação e
interoperação dos sistemas de tratamento da informação, deverá ser obedecida a conformidade deles
com o OSI.
Cada órgão do Governo deverá fazer constar, em seus planos de informatização, as estratégias de
transição de seus sistemas atuais para sistemas com base nas especificações técnicas do POSIG.

Arquitetura de Referência
O Decreto aprova a Arquitetura de Referência do POSIG, publicada como anexo do mesmo Decre-
to.
Essa Arquitetura de Referência é analisada no próximo capítulo desta publicação. Ela abrange as
áreas de redes locais, redes de longa distância, sistemas inter-redes e aplicações. É composta de es-
pecificações técnicas gerais baseadas no OSI, para compra, fabricação, e ensaios de conformidade e
certificação de produtos.

Perfis BRISA
A BRISA9 é uma sociedade civil, sem fins lucrativos, sediada em São Paulo, cujos principais objeti-
vos são preparar os perfis funcionais OSI a serem adotados no Brasil, divulgá-los e promover a utili-
zação do OSI em nosso país. Seus sócios são os fabricantes de equipamentos e programas de proces-
samento de dados, além de usuários. A IBM®® é um dos sócios fundadores da BRISA e tem parti-
cipado ativamente dos eventos por ela promovidos: reuniões, grupos de trabalho, feiras, demonstra-
ções de interoperabilidade, seminários e palestras.

9
BRISA - Sociedade Brasileira Para Interconexão de Sistemas Abertos

9
O Decreto prevê que em 180 dias será publicada uma instrução normativa com as especificações
técnicas do POSIG. Estas especificações detalhadas foram preparadas pela BRISA (são os “perfis
BRISA”) e referem-se às seguintes áreas:
• X.25,
• Token-Ring,
• Ethernet,
• X.400,
• FTAM.

Os interessados terão 30 dias para opinarem a respeito desses perfis funcionais, que se tornarão obri-
gatórios doze meses após sua publicação no Diário Oficial da União.
Os perfis BRISA serão publicados com três partes:
1. Guia do Usuário
2. Guia do Fornecedor
3. Guia de Testes

Os perfis BRISA é que, na realidade, formarão o corpo do POSIG. Por isso, sempre que falarmos de
“POSIG” estaremos nos referindo aos “perfis BRISA”.
Esta será a primeira versão do POSIG, o chamado POSIG-1. Com uma freqüência provável de dois
anos haverá a publicação de novas versões.
O POSIG está baseado no GOSIP inglês.

10
A Arquitetura de Referência

A Arquitetura de Referência, anexo do Decreto No 518, foi elaborada pelo Grupo Técnico No 2 da
Comissão de Coordenação POSIG do PRONOR10.
Além de uma seção de Apresentação, a Arquitetura de Referência é composta das seguintes partes:
• Capítulo 1: Antecedentes
• Capítulo 2: Objetivos, Abrangência e Estrutura
• Capítulo 3: Compatibilidade
• Capítulo 4: Arquitetura
• Capítulo 5: Direções Futuras
• Capítulo 6: Estratégia de Transição
• Anexo I: Lista de Siglas
• Anexo II: Relação das Instituições Participantes

Vamos dar uma olhada, a seguir, em cada um dos capítulos que compõem a Arquitetura de Referên-
cia, exceto os seus Anexos.

Apresentação
Esta seção mostra como o POSIG se enquadra dentro do cenário governamental, em linha com as
diretrizes da reforma administrativa implantada a partir de março de 1990. Como principal função
do POSIG, está a apresentação das diretrizes para a adoção de arquiteturas abertas por parte dos ór-
gãos da Administração Pública Federal (APF).
Os objetivos da adoção do POSIG seriam:
• Assegurar a interoperabilidade dos sistemas de tratamento da informação daqueles órgãos,
• Facilitar o conhecimento e o acesso às informações dos acervos do Setor Público Federal, tan-
to para a sociedade como para o próprio governo,
• Melhoria da qualidade do serviço do Setor Público Federal e modernização e transparência
dos seus processos de gestão.

10
PRONOR - Processo Normativo das Compras do Governo na Área de Informática

11
Capítulo 1: Antecedentes
Aqui é apresentado um histórico das ações e atividades governamentais visando à criação de padrões
para sistemas abertos na área de interoperabilidade, e que resumimos a seguir:
• 1984, Lei de Informática, artigo 4o. Diretriz para a adoção de protocolos abertos de comuni-
cação de dados,
• 1984, portaria MINICOM11/SEI12 colocando o OSI como preferencial nas aquisições dos ór-
gãos da APF,
• 1985, Portaria MINICOM No 100/85, criando grupos de estudos para normalizar os serviços
de vídeo-texto, teletexto, telex, tratamento de mensagens e camada de transporte do modelo
OSI,
• 1986, Primeiro PLANIN13,
• 1986, EMBRATEL14 ativou a RENPAC15,
• 1987, SEI criou o Grupo de Especificações para Aquisição de Redes Locais de Computadores
no Setor Federal – GERL,
• 1988, modelo OSI foi registrado como Norma Brasileira NBR No 10.574,
• 1988, foi constituída a BRISA,
• 1990, as atribuições da SEI passaram para o DEPIN,
• 1990, criação da SAF16/SINFOR17, hoje DINFOR18, cuja atribuição é realizar estudos, formu-
lar diretrizes, orientar normativamente, planejar, coordenar, supervisionar e controlar os as-
suntos referentes aos sistemas e serviços de processamento de dados dos órgãos e entidades
da APF,
• 1990, portaria conjunta SAF/SINFOR e DEPIN/SCT para a implantação do PRONOR, o que
inclui a adoção de perfis funcionais. A comissão que preparou o POSIG é uma das que foram
instaladas para dispor sobre especificações e normalização de matérias de interesse do PRO-
NOR.

11
MINICOM - Ministério das Comunicações, hoje Secretaria Nacional das Comunica-
ções do Ministério dos Transportes e das Comunicações
12
SEI - Secretaria Especial de Informática, hoje DEPIN - Departamento de Políti-
ca de Informática e Automação da SCT - Secretaria de Ciência e Tecnologia
13
PLANIN - Plano Nacional de Informática e Automação
14
EMBRATEL – Empresa Brasileira de telecomunicações S.A.
15
RENPAC – Rede Nacional de Comunicação de Dados por Comutação de Pacotes
16
SAF – Secretaria da Administração Federal, do Ministério do Trabalho e da Ad-
ministração
17
SINFOR - Subsecretaria de Controle de Informática do Setor Público, da SAF
18
DINFOR – Departamento de Administração dos Recursos de Informação e Informáti-
ca, da SAF

12
Capítulo 2: Objetivos, Abrangência e Estrutura Documental

Objetivos
É colocado que o POSIG “... é um conjunto de especificações para protocolos de comunicação de
dados, que permitem a interoperação de sistemas desenvolvidos por diferentes fornecedores e o
intercâmbio de informação entre usuários de diferentes aplicações que utilizam os recursos
destes sistemas”.
O POSIG é baseado nas normas OSI e é aplicável à aquisição de bens e serviços de informação e
informática (no que se refere aos aspectos de comunicação de dados) pelos órgãos da APF. Como
objetivo secundário está a maior facilidade para conduzir licitações e serem realizados os testes de
aceitação dos produtos adquiridos.
Está previsto um processo de certificação, que visa garantir que os produtos oferecidos em uma lici-
tação possuem aderência aos padrões estabelecidos pelo POSIG. Inicialmente deverão existir dois
tipos de certificação:
• Teste de conformidade, para verificar se o produto atende aos requisitos de um determinado
padrão, e
• Teste de interoperabilidade, para verificar se o produto interage efetivamente com outros sis-
temas.

O teste de conformidade deve ser realizado por “...entidades independentes credenciadas pelo go-
verno brasileiro...”. Ele “... é fundamental e será pré-requisito indispensável para assinatura
de contratos”.
Espera-se que dentro em breve a BRISA seja oficialmente credenciada a fornecer os chamados “Cer-
tificados de Conformidade”. Seriam os documentos que atestam se os produtos de um determinado
fornecedor aderem e seguem os padrões do POSIG, podendo, então, ser adquiridos pelos órgãos do
Governo.
Oficialmente a BRISA informou que não serão “certificados de conformidade”, mas sim “certifica-
dos de produtos que estejam inseridos em um processo de garantia de interoperabilidade”. Na práti-
ca, imagina-se que funcionarão como certificados de conformidade mesmo. A BRISA pretende emi-
ti-los depois de cumpridas as seguintes formalidades (para cada produto):
• Declaração do fornecedor, via preenchimento (e autenticação) do PICS19 da BRISA.
Os PICSs são documentos formais previstos no mundo OSI, publicados pelos fornecedores,
com as especificações técnicas detalhadas de cada produto. A BRISA possui um modelo de
PICS para cada padrão do OSI que está sendo agora adotado no Brasil. É este modelo que
deve ser preenchido pelo fornecedor, com as especificações técnicas do seu produto, de modo
que a BRISA possa analisar se ele atende aos padrões mínimos por ela definidos.
A confecção desses modelos da BRISA foi acompanhada pelos profissionais da IBM® Brasil.
Serão tomadas ações para que os PICSs da BRISA sejam preenchidos o mais breve possível,
de modo a acelerarmos os processos de certificação dos nossos produtos.

19
PICS – Protocol Implementation Conformance Statement

13
• Relatório de teste de conformidade emitido por Laboratório reconhecido pela BRISA (inclu-
sive do exterior).
Diversos laboratórios da IBM® e de outras entidade tem feito, ao longo do tempo, testes de
conformidade e/ou interoperabilidade com os nossos produtos. Dentre eles destaca-se o nos-
so laboratório de La Gaude, França, que tem credibilidade mundial. A BRISA aceitará os re-
latórios dos laboratórios IBM®.
Esses relatórios estão em fase de obtenção.

• Demonstrações e/ou testes de interoperabilidade, coordenados e acompanhados pela BRISA,


entre os fornecedores.
A BRISA pretende, em futuro próximo, montar uma rede para promover estas demonstra-
ções/testes. Será a BRISANET. Enquanto isto não ocorre, imagina-se que esses testes serão
conduzidos de forma artesanal, com um número pequeno de parceiros e com uma abrangência
limitada.
Desde 1990 a IBM® vem participando dos eventos de interoperabilidade promovidos pela
BRISA, onde o ponto alto tem sido a boa “performance” dos nossos produtos de OSI em tes-
tes públicos de interoperabilidade com os produtos de nossos concorrentes.

• Declaração do fornecedor de que resolverá, no campo, os eventuais problemas de interopera-


bilidade que venham a ocorrer em seus clientes, após a instalação dos seus produtos de OSI.
Tem sido um compromisso de honra da IBM® Brasil o suporte aos seus clientes, antes, du-
rante e após a instalação dos produtos por ela comercializados.

Abrangência
Em seu texto, a Arquitetura de Referência diz que o POSIG é para ser adotado em todos “... os ór-
gãos e entidades da Administração Pública Federal direta ou indireta, inclusive as fundações
instituídas ou mantidas pelo Poder Público, as empresas estatais, as sociedades de economia
mista e demais organizações sob o controle direto ou indireto da União. Outrossim, será facul-
tada a aplicação do POSIG para os sistemas táticos de uso dos órgãos oficiais de segurança e
das operações militares das Forças Armadas”.
Mesmo não sendo de adoção obrigatória pelas Forças Armadas, é de se esperar que estas instituições
também se preocupem em aderir ao POSIG. Isto virá de encontro à flexibilidade desejada pelo Go-
verno para a interconexão entre os seus diversos órgãos.
Embora esteja fora da abrangência do POSIG, há a expectativa de que ele também venha a ser adota-
do pelos governos estaduais e municipais, pelos Poderes Legislativo e Judiciário, assim como pela
iniciativa privada.
A Arquitetura de Referência define, como prioritárias, as áreas de processamento distribuído e auto-
mação de escritório e as aplicações de correio eletrônico, transferência de arquivos, intercâmbio de
textos processáveis e documentos formatados, intercâmbio eletrônico de dados, interação através de
terminais e intercâmbio de gráficos.

14
Apesar de prioritárias, algumas dessas áreas ainda não tiveram os seus padrões definidos dentro do
OSI. é o que acontece, por exemplo, com o processamento distribuído, e o intercâmbio de textos pro-
cessáveis e documentos formatados.
Desta forma, fica aberto o caminho para a utilização de outros padrões que não os do OSI, nos casos
em que estes não puderem atender às necessidades imediatas dos usuários. Isto está claro no texto da
Arquitetura de Referência, quando é dito que não ficarão excluídos outros padrões para assegurar a
interoperabilidade entre sistemas heterogêneos, na fase de transição para a adequação ao POSIG, ou
quando não houver produtos que implementem os padrões OSI.

Estrutura Documental
Haverá versões sucessivas do POSIG, conforme o dinamismo da tecnologia e do processo de norma-
lização. Estas versões serão compatíveis entre si.
Elas serão estruturadas em três conjuntos de especificações:
• Guia para uso dos usuários (nos processos de licitação),
• Guia para uso dos fabricantes,
• Guia para uso das instituições responsáveis pelos testes de conformidade.

O POSIG estabelecerá quais perfis serão obrigatórios e quais serão apenas recomendados.

Capítulo 3: Compatibilidade
O POSIG terá compatibilidade internacional com os GOSIPs, mas privilegiará os padrões do Sistema
Nacional de Metrologia, Normalização e Qualidade Industrial. Seus perfis funcionais levarão em
consideração os perfis da BRISA e serão adotadas as Normas Brasileiras da ABNT, as Práticas TE-
LEBRÁS20 e outros trabalhos sobre normalização, sempre que disponíveis e aplicáveis no contexto
do POSIG.
Será procurada a compatibilidade com as normas da ISO, do CCITT e do IEEE. O POSIG prevê o
reconhecimento mútuo de relatórios e resultados de testes de conformidade realizados por entidades
independentes (“third part testers”).

Capítulo 4: Arquitetura
Este é o capítulo que dá as diretrizes técnicas básicas do POSIG. Ele cita genericamente as normas
da ISO que deverão ser atendidas pelos produtos OSI nesta primeira versão do POSIG.

20
TELEBRÁS – Telecomunicações Brasileiras S.A.

15
Modelo de Transporte
As quatro camadas inferiores da arquitetura OSI foram agrupadas em um modelo único, o POSIG-T,
em virtude do entendimento de que elas estão relacionadas com as características da sub-rede de
transporte.
O POSIG-T não exige que todos os diversos tipos de sub-redes sejam suportados por uma única im-
plementação. Fica a critério de cada fornecedor se um determinado protocolo será implemen-
tado por “hardware” ou “software”.
A seguir, as definições e/ou descrições gerais dos três tipos de sub-redes de transporte previstas no
capítulo 4 (redes locais, redes de longa distância e sistemas inter-redes).

1. Redes Locais
São as redes com área de atuação restrita, geralmente entre 0,1 e 10 km, onde a taxa de trans-
ferência binária é da ordem de vários Megabits por segundo (Mbps).
O POSIG adotará redes locais baseadas em CSMA/CD21 (norma ISO 8802-3) e Token-Ring
(norma ISO 8802-5).
Os protocolos a serem usados por esses dois métodos de acesso serão:
• Na camada de enlace - protocolo LLC22, classe 1 (serviço sem conexão), norma
ISO 8802-2,
• Na camada de rede - protocolo que fornece serviço sem conexão, CLNS23, norma
ISO 8473,
• Na camada de transporte - protocolo que fornece serviço com conexão, norma ISO
8073, classe 4.

Para uma rede CSMA/CD serão aceitas as seguintes opções de cabos:


• 10base5 - cabo coaxial, 10Mbps - norma ISO 8802-3, capítulo 8,
• 10base2 - cabo coaxial, 10Mbps - norma ISO 8802-3, capítulo 10,
• 10base-T - par trançado, 10Mbps.

O programa IBM® OSI/CS for OS/2EE - OSI/Communications Subsystem for OS/2EE


(5871-BBB, P/N 49F4807) atende aos requisitos do POSIG-T para as redes locais (ca-
madas de rede e transporte). A camada de enlace é suportada por todos os adaptadores
de redes locais IBM®.
A IBM® não tem suporte, até o momento, para a especificação opcional 10base-T (par tran-
çado). Está sendo iniciado o processo para a homologação das placas IBM® X.25 e IBM®
ARTIC junto à EMBRATEL.

21
CSMA/CD – Carrier Sense, Multiple Access with Collision Detection
22
LLC – Logical Link Control
23
CLNS – Connectionless-mode Network Services

16
2. Redes de Longa Distância
São as redes para a interligação de sistemas geograficamente distantes. Como protocolo de
acesso à rede foi padronizado o padrão X.25 do CCITT. Ele define a interface entre um
DTE24, do lado do usuário, e um DCE25, que pertence à rede.
Poderão ser usadas a RENPAC, a TRANSDATA26, linhas privativas ponto-a-ponto e/ou a re-
de telefônica analógica.
A RENPAC utiliza o protocolo de acesso à rede X.25. O POSIG aceita as classes 0, 2 ou 4,
na camada de transporte (norma ISO 8073), conforme o tipo de ligação, se direta à RENPAC
ou via STM-40027.

Para linhas privativas, TRANSDATA e rede telefônica analógica, devem ser utilizados:
• Na camada de enlace - protocolo HDLC28-LAPB29, norma ISO 7776,
• Na camada de rede - protocolo PLP30, norma ISO 8208,
• Na camada de transporte - classes 0, 2 ou 4 do protocolo de transporte, norma ISO
8073.

Os seguintes produtos da IBM®, para as plataformas MVS, VM, AS/400 (S/400) e


RS/6000, atendem às exigências do POSIG-T para as redes de longa distância:
• Ambientes MVS e VM
• NPSI - NCP PACKET SWITCHING INTERFACE , diversos códigos,
roda nas Controladoras de Comunicações 37XX,
• OSI/CS - OSI Communications Subsystem (5685-014) – MVS, e
• OSI/CS - OSI Communications Subsystem (5684-013) – VM.

• Ambiente AS/400 (S/400)


• OSICS/400 - OSI Communications Subsystem/400 (5738-OS1).

• Ambiente RS/6000
• AIX/6000 (5756-030),
• OSIMF/6000 - OSI Message and Filing/6000 (5756-085).

24
DTE – Data Terminal Equipment
25
DCE – Data Circuit-terminating Equipment
26
TRANSDATA – Serviço de Comunicação de Dados Ponto-a-Ponto da EMBRATEL
27
STM-400 – Serviço de Tratamento de Mensagem, a rede pública de Correio Eletrô-
nico da EMBRATEL
28
HDLC – High-level Data Link Control
29
LAPB – Link Access Protocol, Balanced
30
PLP – Packet Layer Protocol

17
3. Sistemas Inter-redes
A interligação entre sub-redes de transporte poderá ser feita conforme as características delas,
em quaisquer das camadas física, de enlace ou de rede. A única restrição refere-se à interliga-
ção de redes locais CSMA/CD: será feita na camada física, via repetidores (norma ISO 8803-
2, capítulo 9).
Poderá ser feita na camada de rede a interligação direta de sistemas terminais, via sistemas in-
termediários (norma ISO 8473, complementada pelo protocolo de roteamento ES-IS31, servi-
ço sem conexão – norma ISO 9542).
Está prevista a interligação via RENPAC:
• Interligação de redes locais através de sistemas intermediários - utilizar o protoco-
lo X.25, o protocolo LLC classe 1 (norma ISO 8802-2), o método de acesso da
própria rede local e o protocolo de rede CLNS (norma ISO 8473), e
• Interligação de processadores entre si ou de processador com rede local através de
sistemas intermediários - utilizar o protocolo X.25 para acesso à RENPAC.
Na camada de transporte deverão ser usadas as classes 2 ou 4 do serviço de trans-
porte com conexão (norma ISO 8073), independente do tipo de interligação.

Modelo de Aplicação
Pela Arquitetura de Referência tudo que se passa acima da camada de transporte está relacionado
com os processos de aplicação. Por isso, o POSIG grupará as três camadas superiores num modelo
único, o POSIG-A.
O POSIG-A deixa a critério do fornecedor a maneira de implementar as suas aplicações, se num úni-
co produto ou em produtos múltiplos. A seguir, as definições e/ou descrições gerais dos dois tipos de
aplicações previstas no capítulo 4 (sistemas de tratamento de mensagens e transferência de arquivos):
1. Sistema de Tratamento de Mensagens
É o MHS, comumente chamado de Correio Eletrônico (recomendação X.400 do CCITT). O
POSIG-A exige aderência à versão 1984 do X.400.
Há um aviso de que o POSIG-A manterá compatibilidade com a rede STM-400.

São as seguintes as especificações para as três camadas superiores:


• Camada de aplicação - X.400 de 1984,
• Camada de apresentação - nada é definido, pois o POSIG-A entende que as funcionalida-
des desta camada já estão incorporadas na camada de aplicação,
• Camada de sessão - unidades funcionais (“functional units”) a serem implementadas
(norma ISO 8327):
• núcleo (“kernel”),

31
ES-IS – End System-Intermediate System

18
• “half-duplex”,
• exceções (“exceptions”),
• gerência de atividade (“activity management”), e
• sincronização secundária (“minor synchronize”).

Os produtos OSI da IBM® para as plataformas MVS, VM, AS/400 (S/400), RS/6000 e
OS/2EE atendem às exigências do POSIG-A para um Sistema de Tratamento de Mensa-
gens:
• Ambiente MVS
• ONDS - Open Network Distribution Services (5695-043),
• X.400 DISOSS Connection (5785-GCF), e
• OSI/CS - OSI Communications Subsystem (5685-014).

• Ambiente VM
• ONDS - Open Network Distribution Services (5684-139),
• X.400 PROFS Connection (5785-GCG), e
• OSI/CS - OSI Communications Subsystem (5684-013).

• Ambiente AS/400 (S/400)


• OSIMS/400 - OSI Message Services/400 (5738-MS1), e
• OSICS/400 - OSI Communications Subsystem/400 (5738-OS1).

• Ambiente RS/6000
• OSIMF/6000 - OSI Message and Filing/6000 (5756-085).

• Ambiente OS/2EE
• OSI/CS for OS/2EE - OSI/Communications Subsystem for OS/2EE
(5871-BBB, P/N 49F4807).
Obs: A solução IBM® para a plataforma OS/2EE ainda não está completa.
Falta a implementação para a camada de aplicação.

2. Transferência de Arquivos
Seu nome completo é Transferência, Acesso e Gerenciamento de Arquivos, ou FTAM: “File
Transfer, Access and Management” (norma ISO 8571).

19
Essa norma ISO permite que o usuário:
• Transporte arquivos,
• Acesse atributos de arquivos,
• Manipule arquivos,
• Estabeleça a comunicação entre arquivos, e
• Tenha facilidades para gerenciar arquivos.

O POSIG-A tratará apenas da transferência simples de arquivos não formatados.

São as seguintes as especificações para as três camadas superiores:


• Camada de aplicação - padrão FTAM (norma ISO 8571),
• Camada de apresentação - unidade funcional núcleo do protocolo de apresentação (norma
ISO 8823),
• Camada de sessão - unidades funcionais (“functional units”) a serem implementadas
(norma ISO 8327):
• núcleo (“kernel”),
• “duplex”,
• ressincronização (“resynchronize”) ==> opcional, e
• sincronização secundária (“minor synchronize”) ==> opcional.

Os produtos OSI da IBM® para as plataformas MVS, VM, AS/400 (S/400), RS/6000 e
OS/2EE atendem às exigências do POSIG-A para a Transferência de Arquivos:
• Ambiente MVS
• OSI/FS - OSI/File Services (5685-046), e
• OSI/CS - OSI Communications Subsystem (5685-014).

• Ambiente VM
• OSI/FS - OSI/File Services (5684-038), e
• OSI/CS - OSI Communications Subsystem (5684-013).

• Ambiente AS/400 (S/400)


• OSIFS/400 - OSI File Services/400 (5738-FS1), e
• OSICS/400 - OSI Communications Subsystem/400 (5738-OS1).

20
• Ambiente RS/6000
• OSIMF/6000 - OSI Message and Filing/6000 (5756-085).

• Ambiente OS/2EE
• OSI FS/2 - OSI File Services/2 (5601-211, P/N 50F1234), e
• OSI/CS for OS/2EE - OSI/Communications Subsystem for OS/2EE
(5871-BBB, P/N 49F4807).

Repertório de Caracteres
O POSIG agrupa os possíveis repertórios de caracteres a serem usados na representação dos dados no
modelo denominado POSIG-C.
É obrigatório o suporte ao repertório definido pela norma ABNT NBR32-9611, também denominada
CBII33.

Capítulo 5: Direções Futuras


As próximas versões do POSIG deverão ter uma abrangência maior, incluindo diversos outros pa-
drões, há medida em que eles mostrem estabilidade em âmbito internacional.
A seguir estão as direções futuras do POSIG. Não está definido em que versão será incluído um de-
terminado padrão. As Direções Futuras servem tão somente como um balizador para os fornecedores
e usuários: os primeiros podem orientar suas prioridades (em termos de novas implementações), en-
quanto que os segundos podem preparar seus projetos de médio e longo prazo já levando em conta
essas novas implementações.

Tendências Futuras Para o POSIG-T


São as seguintes:
• Fibra ótica Para Redes de Alta Velocidade.
Para utilização em redes locais, provavelmente seguindo as recomendações para FDDI34 da
norma ISO 9314.

• Redes Digitais de Serviços Integrados (RDSI).


A tecnologia RDSI ou ISDN35 deverá ser utilizada para combinar a transmissão de voz, dados
e imagem via linhas digitais de alta velocidade. Terá emprego nas sub-redes de transporte,
dando suporte a novas aplicações, tais como fac-símile grupo IV e videotelefonia.

32
NBR – Norma Brasileira
33
CBII – Código Brasileiro para Intercâmbio de Informações
34
FDDI – Fiber Distributed Data Interface

21
• Redes Metropolitanas.
Serão incluídos os serviços MAN36 para interconexão de redes locais, em âmbito metropoli-
tano (até 100 km de distância), a velocidades que vão de 34 até 140 Mbps. Estão previstos os
serviços de comunicação de dados, voz e imagem.

• Acesso à RENPAC.
As recomendações X.25 de 1988 serão incorporadas ao POSIG.

Tendências Futuras Para o POSIG-A


São as seguintes:
• Tratamento de Mensagens (MHS-88).
Serão incorporadas as recomendações X.400 de 1988 e também as especificações do CCITT
para EDIM37, segundo as recomendações F.435 e X.435 do CCITT. No Brasil o EDIM ga-
nhou o nome de “Sistema de Mensageria EDI38”.

• Serviços de Diretório.
Os perfis funcionais serão baseados na norma ISO 9594 e nas recomendações de 1988 para
X.500, do CCITT. Estão previstos diretórios centralizados e distribuídos, além do suporte a
uma estrutura genérica de informação a ser utilizada por um grande número de aplicações.

• Transferência, Acesso e Gerenciamento de Arquivos (FTAM).


Serão incorporadas as normas que prevêem, dentre outros serviços, a transferência de arqui-
vos estruturados e o acesso a arquivos complexos.

• Terminal Virtual.
Estão previstas as especificações para terminal virtual, processamento distribuído e acesso
remoto a bases de dados.

Tendências Futuras Para o POSIG-F


Haverá o novo POSIG-F, que tratará dos formatos para o intercâmbio de dados e documentos. Ele
dará suporte aos serviços de aplicação definidos pelo POSIG-A, abrangendo:
• Textos e documentos,

35
ISDN – Integrated-Services Digital Network
36
MAN – Metropolitan Area Network
37
EDIM – Electronic Data Interchange Messaging
38
EDI – Electronic Data Interchange

22
• Arquivos de dados não estruturados (binários), e
• Arquivos e mensagens de dados estruturados.

Estes formatos, que incluirão também gráficos e imagens, são mais específicos do que aqueles defi-
nidos nos perfis FTAM e MHS, porém estes últimos poderão ser utilizados até à incorporação daque-
les no POSIG.
São as seguintes as tendências futuras para o POSIG-F:
• Formatos Para Intercâmbio de Documentos.
Para essa área, deverá ser empregada a norma ISO 8613, que padroniza a arquitetura ODA39
(ADA, em português, “Arquitetura de Documentos Administrativos”), e o ODIF40 (FIDA, em
português, “Formato de Intercâmbio de Documentos Administrativos”).
O ODA prevê o intercâmbio de documentos padronizados em ambientes de escritórios, tais
como textos, fac-símile e gráficos.
Serão três os formatos para o intercâmbio de documentos, seguindo o perfil ODA/ODIF:
• Formatado.
Permite que um documento possa ser visualizado ou impresso apenas na sua forma
final.
• Processável.
Permite pós-processamento de edição e/ou reformatação por parte do destinatário.
• Formatado e Processável.
Permite tanto a visualização e a impressão na sua forma final quanto o pós-
processamento pelo destinatário.

Quanto à estrutura dos documentos, o perfil ODA/ODIF definirá:


• Estrutura Lógica - relacionada com a estrutura do documento, e
• Estrutura de Apresentação - relativa ao “layout” do documento.

Serão dois os níveis para o intercâmbio de documentos, seguindo o ODA/ODIF, cada um de-
les aceitando, no mínimo, o formato processável:
• Nível 1.
Apenas para o intercâmbio dos textos produzidos pela maioria dos processadores
de textos de última geração.

39
ODA – Office Document Architecture
40
ODIF – Office Document Interchange Format

23
• Nível 2.
Incluirá o intercâmbio de gráficos, imagens digitalizadas e estruturas documentais
mais complexas.

• Em versões futuras, o POSIG também irá prever os documentos elaborados por sistemas de
editoração eletrônica.

• Formatos para Intercâmbio de Dados.


Os padrões EDI serão incorporados às versões futuras do POSIG, de acordo com as seguintes
normas ISO:
• ISO 9735 – EDIFACT41, Application Level Syntax Rules, e
• ISO 7372 - Trade Data Interchange and Trade Data Elements Directory.

O EDI descreve formatos para transações comerciais tais como pedidos, ordens de pagamen-
to, remessas, faturas, cobranças e outras.
Embora haja diversos outros padrões para EDI, como o ANSI X.12 da ANSI e o UN GTDI42
da ONU, o POSIG privilegiará o EDIFACT. Também serão levados em conta os trabalhos de
um recém-criado subcomitê da ABNT para estudar esses assuntos.

Tendências Futuras Para o POSIG-S


Será criado o POSIG-S para fornecer padrões diversos sobre comunicação de dados e serviços de
ordem geral.
São as seguintes as tendências futuras para o POSIG-S:
• Serviços de Gerenciamento.
Serão as especificações sobre o controle básico dos enlaces físicos e para a gerência efetiva de
todos os recursos da rede e das interconexões.

• Serviços de Segurança.
Estão previstos serviços de segurança, principalmente no que diz respeito ao controle do aces-
so à rede e aos dados, inclusive o uso de criptografia.

41
EDIFACT – Electronic Data Interchange for Administration, Commerce and Trans-
port
42
GTDI – United Nations Guidelines on Trade Data Interchange

24
Interface Para Programa de Aplicação
O POSIG procurará dar prioridade ao assunto API43. Ficará na dependência do desenvolvimento de
normas internacionais.

Capítulo 6: Estratégia de Transição


A idéia do POSIG é que cada órgão do Governo Federal faça seu próprio controle sobre as compras
de bens e serviços de informática. A implantação do POSIG é uma estratégia de longo prazo, visan-
do à migração do parque computacional hoje instalado (incluindo “hardware” e “software”) para um
conjunto de sistemas interoperáveis.
Os dirigentes de cada órgão deverão preparar diretrizes detalhadas para a migração.

Definição da Estratégia
Fica muito clara a obrigatoriedade de serem revistos e atualizados os atuais planos de informática dos
órgãos do Governo Federal. Estes planos devem estar incluídos nos planos estratégicos globais das
entidades, com o engajamento dos seus mais altos níveis de direção.
Uma política clara e bem definida deve ser adotada e, só então, devem ser preparados os planos de
transição, incluindo prazos e mecanismos para a implantação da arquitetura definida pelo POSIG.
Deve ser levado em consideração o ciclo de vida dos sistemas envolvidos. É importante preservar os
recursos de “hardware” e “software” hoje existentes, assim como os investimentos até hoje realiza-
dos (incluindo pessoal).
Dessa forma, a migração para o POSIG deve ser coordenada com os planos de substituição e moder-
nização dos sistemas computacionais e das redes de maior porte do órgão. Devem ser previstas, den-
tre outras atividades, o projetos de redes, licitação dos bens e serviços envolvidos.

Diretrizes Gerais Para a Transição


São os seguintes os principais pontos a serem observados dentro de um processo de transição:
• Devem ser analisados requisitos funcionais e de desempenho. Levar em conta...
• o nível de interoperabilidade necessário,
• o custo de implementação,
• o custo de manutenção,
• a adequação aos planos de modernização, e
• a importância de apontar o nível de controle (ou gerência) da rede, para a obtenção de ser-
viços confiáveis.

43
API – Application Program Interface

25
• Relacionar as novas aquisições com a estratégia e o plano de transição.
• Devem ser privilegiadas as implementações que não utilizem “gateways”, a nível de sistema,
como solução definitiva.
• Prever os requisitos futuros, a fim de incorporar novos produtos OSI quando se tornarem dis-
poníveis.
• É fundamental preservar o parque instalado.
• Os sistemas proprietários devem ser realocados para tarefas que não requeiram comunicação
de dados (ou substituídos).
• Pode haver transições não suaves. Às vezes poderá ser necessário sacrificar o custo e a e-
ficiência a curto prazo, em favor de um planejamento que vise a interoperabilidade a
médio e/ou longo prazo.
• É recomendado o auxílio dos fornecedores no desenvolvimento da estratégia de transi-
ção e na migração.
• Na transição, o fornecedor deverá garantir os níveis de funcionalidade e os serviços prestados.
O impacto nas aplicações deverá ser mínimo.

26
Conclusões

A adoção do modelo de referência OSI por diversos governos vem de encontro aos ideais básicos da
ISO. Ela estabelece, em suas definições, que o seu modelo deve ser usado para promover a interope-
rabilidade entre implementações de diferentes fornecedores.
Por essas definições, que também constam das normas publicadas pela ABNT, fica claro, e ló-
gico, que a ligação entre sistemas de um mesmo fabricante podem, e devem, usar as arquitetu-
ras de comunicações de cada fornecedor, pois estas lhes permitirão obter melhor desempenho e
funcionalidade.
Dessa forma, o OSI deve ser empregado para a interconexão entre os sistemas produzidos por dife-
rentes fabricantes: obtém-se a padronização das interfaces que promovem interoperabilidade, e des-
carta-se as implementações particulares, visando a flexibilidade total em termos de produtos e servi-
ços.
Devemos estar conscientes que a adoção de soluções OSI apresenta todas as dificuldades inerentes a
uma implementação deste porte. Isto é válido para qualquer fornecedor, em qualquer país, inclusive
o Brasil. Trata-se de uma arquitetura nova, ainda não completamente definida, pouco difundida, de
modo que haverá inúmeras dificuldades a transpor. Por outro lado, só com iniciativas do porte de um
POSIG é que haverá a disseminação de toda essa nova cultura.
Ciente dos novos tempos e da importância que representa dentro do mercado de processamento e
comunicação de dados, a IBM® está pronta a cumprir o seu papel com relação ao POSIG. Estaremos
sempre dispostos a apoiar as iniciativas dos nossos clientes em projetos para a adoção do modelo
OSI. Temos certeza que os nossos produtos apresentam soluções de qualidade, sólidas, de acordo
com a arquitetura SAA44, e adequadas para integrar os nossos clientes ao mundo OSI.

44
SAA – Systems Application Architecture

27
Apêndice

Glossário de Termos Relacionados ao OSI

ABNT Associação Brasileira de Normas Técnicas


ACSE Association Control Service Element
ADMD Administration Management Domain
ANSI American National Standards Institute
API Application Program Interface
APPC Advanced Program-to-Program Communications
ASN.1 Abstract Syntax Notation 1
BRISA Sociedade Brasileira Para Interconexão de Sistemas Abertos
BT British Telecom
CCITT Comité Consultif International de Télégraphie et Téléphonie
CEN Comité Europeen de Normalisation
CENELEC Comité Europeen de Normalisation Electrotechnique
CEPT Conference Europeene des Administrations des Postes et des
Telecomunications
CLNS Connectionless-mode Network Service
CMIP Common Management Information Protocol
CMIS Common Management Information Service
COS Corporation for Open Systems
COSAC Canadian Open Systems Application Criteria
CSA Canadian Standards Association
CSMA/CD Carrier Sense, Multiple Access with Collision Detection
CUA Common User Agent
DBP Deutsche Bundespost
DCA Document Content Architecture
DCE Data Circuit-terminating Equipment
DIA Document Interchange Architecture
DIN Deutsches Institut fur Normung e.V.
DTE Data Terminal Equipment
DUA Directory User Agent

28
ECMA European Computer Manufactures’ Association
EDI Electronic Data Interchange
EDIFACT Electronic Data Interchange for Administration, Commerce and
Transport
EDIM Electronic Data Interchange Messaging
EIA Electronics Industries Association
ES-IS End System-Intermediate System
FDDI Fiber Distributed Data Interface
FTAM File Transfer, Access and Management
GOSIP Government OSI Profiles
HDLC Higl-level Data Link Control
IEEE Institute of Electrical and Electronics Engineers
INTAP Interoperability Technology Association for Information Processing
ISDN Integrated Services Digital Network
ISSO International Standards Organization
ITU International Telecommunications Union
JTC 1 Joint Technical Comittee 1
LAPB Link Access Protocol, Balanced
LLC Logical link Control
MAN Metropolitan Area Network
MAP Manufacturing Automation Protocol
MHS Message Handling System (X.400)
MTA Message Transfer Agent
MTF Message Transfer Facility
MTS Message Transfer System (X.400)
NIST National Institute of Standards and Technology
NPSI X.25 NCP Packet Switching Interface
ODA Office Document Architecture
ODIF Office Document Interchange Format
ONDS Open Network Distribution Services
OSI Open Systems Interconnection
OSI/CS OSI/Communications Subsystem
OSI/FS OSI/File Services
OSIMF/6000 OSI Message and Filling/6000

29
OSIMS/400 OSI Message Services/400
PICS Protocol Implementation Conformance Statement
PDU Protocol Data Unit
PLP Packet Layer Protocol
POSIG Perfil OSI do Governo Brasileiro
PRMD Private Management Domain
PSDN (X.25) Packet Switched Data Network
P1 Message Transfer Protocol
P2 Inter-Personnal Message Protocol
P3 Submission and Delivery Protocol
RPI Remote Programming Interface
SAA Systems Application Architecture
SDE Submission and Delivery Entity
SNADS SNA Distribution Services
SPAG Standards Promotion and Applications Group
TCP/IP Transmission Control Protocol/Internet Protocol
TOP Technical and Office Protocols
UA User Agent (X.400)
UN GTDI United Nations Guidelines on Trade Data Interchange
VT Virtual Protocol
XDC X.400 DISOSS Connection
XPC X.400 PROFS Connection

*****

30

You might also like