FATEC - FACULDADE DE TECNOLOGIA DE SÃO JOSÉ DOS CAMPOS

JOVAN ANGELO RODRIGUES DE SOUZA, PAULO ALVES FRANÇA

INTEGRANDO UMA SOLUÇÃO DE BAIXA PLATAFORMA

COM MAINFRAME UTILIZANDO IBM WEBSPHERE MQ E CICS

SÃO JOSÉ DOS CAMPOS

2011
 i

JOVAN ANGELO RODRIGUES DE SOUZA, PAULO ALVES FRANÇA

INTEGRANDO UMA SOLUÇÃO DE BAIXA PLATAFORMA

COM MAINFRAME UTILIZANDO IBM WEBSPHERE MQ E CICS

Trabalho de graduação apresentado a Faculdade

de tecnologia de São José dos Campos, como parte dos
requisitos necessários para obtenção do título de
Tecnólogo em Banco de dados.

Orientador: Rogério Marinke.

SÃO JOSÉ DOS CAMPOS

2011
 ii

JOVAN ANGELO RODRIGUES DE SOUZA, PAULO ALVES FRANÇA

INTEGRANDO UMA SOLUÇÃO DE BAIXA PLATAFORMA

COM MAINFRAME UTILIZANDO IBM WEBSPHERE MQ E CICS

Trabalho de graduação apresentado a Faculdade

de tecnologia de São José dos Campos, como parte dos
requisitos necessários para obtenção do título de
Tecnólogo em Banco de dados.

________________________________________________________
PAULO HENRIQUE CRUZ JUNIOR - MESTRE

________________________________________________________
LUDMILA CANUTO DE MELO FERREIRA SALIMENA – ESPECIALISTA

________________________________________________________
ROGÉRIO MARINKE - ESPECIALISTA

___/___/___
DATA DE APROVAÇÃO
 iii

Dedicamos este trabalho aos nossos amigos, familiares e professores

que nos ajudaram a trilhar os caminhos e superar
os inúmeros desafios para galgar
o sucesso e a realização.
 iv

AGRADECIMENTOS

Agradecemos ao professor e orientador Rogério Marinke pelo apoio, encorajamento e

pelo tempo empregado na qualidade deste trabalho tanto quanto empregado na discussão,
sempre aberta estimulante, de novas idéias. Também agradecemos a equipe IBM Ludmila
Canuto de Melo Ferreira Salimena, Paulo Henrique Cruz, Rogério Salgado Rocha, Célio
Costa Carvalho, Eugenio Fernandes, André Luiz dos Santos Gonçalves, Tadeu Moraes e
Aroldo Yuji Yai por incutir em nós a necessidade de aprender sempre, pelo apoio técnico
fornecido e o acesso aos ambientes, sem o quais a concretização desse trabalho seria inviável.
 v

RESUMO

Este trabalho propõe uma arquitetura de integração entre baixa e alta plataforma utilizando
Web Services, IBM Websphere MQ Client, IBM Websphere MQ e CICS Transaction Server.
O estudo de caso tem como aplicação prática a nota fiscal eletrônica. O objetivo é propor uma
forma alternativa para transmitir a nota fiscal eletrônica utilizando recursos de fila de
mensagens disponíveis no mainframe pelo middleware IBM Websphere MQ. Esta arquitetura
terá dois componentes de software. O primeiro uma aplicação desktop que será responsável
por transmitir a nota fiscal para outro componente alocado no mainframe. Este componente se
conectará através do Web Service ao servidor da Secretaria da Fazenda a fim de transmitir a
nota fiscal eletrônica e posteriormente receber o status da nota enviada.

Palavras-chave: Mainframe, nota fiscal eletrônica, Web Service, certificado digital.

 vi

ABSTRACT

An integration architecture between low and high platform using Web Services, IBM
Websphere MQ Client, IBM Websphere MQ and CICS transaction Server is proposed in this
work. The study of case has as practical application the electronic invoice. The objective is to
propose an alternative form to broadcast the electronic invoice using the resources of message
queues available in the mainframe by middleware IBM Websphere MQ. This architecture will
have two software components. The former is a desktop application that will be responsible
for broadcasting the electronic invoice to another component allocated in the mainframe. This
component will connect through Web Service to the server of the government tax bureau
intending to broadcast the electronic invoice and posteriorly receiving the status of the sent
invoice.

Keywords: Mainframe, Web Service, Digital Certificate.

 vii

LISTA DE FIGURAS
Figura 1 - Infra-estrutura dos componentes CORBA......................................................... 19
Figura 2 - Ambientes integrados utilizando o Object Broker do CORBA........................ 22
Figura 3 - Estrutura geral da ICP-Brasil. ............................................................................ 27
Figura 4 - Dados de Identificação do Certificado digital. ................................................... 29
Figura 5 - Todos os dados contidos no certificado digital, aba Detalhe ............................ 30
Figura 6 – Funcionamento da SEFAZ virtual. .................................................................... 33
Figura 7 – Processo de envioda NF-e ao ambiente virtual da SEFAZ. ............................. 34
Figura 8 - Canal de comunicação cliente servidor de uma aplicação WMQ. ................... 37
Figura 9 – Exemplo código COBOL com RDZ. .................................................................. 40
Figura 10 – Arquitetura de integração da aplicação desktop com o mainframe. ............ 42
Figura 11 – Processo de envio da NF-e para o mainframe. ................................................ 43
Figura 12 – Seleção de um arquivo XML da NF-e preenchida. ......................................... 44
Figura 14 – Código Fonte da implementação da classe Consulta.java.............................. 46
Figura 15 – Diagramas de classe da aplicação desktop....................................................... 47
Figura 16 – Tela de administração do WMQ....................................................................... 48
Figura 17 – Código Fonte do componente NFERECEP.cbl ............................................... 49
 viii

LISTA DE TABELAS
Tabela 1 - Vantagens e desvantagens da utilização de Web Service.................................. 25
Tabela 2 - Vantagens e desvantagens da utilização de CORBA. ....................................... 26
 ix

SUMÁRIO

1.INTRODUÇÃO ................................................................................................................... 11
1.1 Motivação .......................................................................................................................... 11
1.2 Objetivos............................................................................................................................ 12
1.2.1 Objetivo geral................................................................................................................. 12
1.2.2 Objetivos específicos...................................................................................................... 12
1.3 Metodologia....................................................................................................................... 13
1.4 Organização do trabalho ................................................................................................. 14
2 INTEGRAÇÃO DE BAIXA COM ALTA PLATAFORMA........................................... 15
2.1 Baixa plataforma .............................................................................................................. 15
2.2 Alta Plataforma ................................................................................................................ 15
2.3 Arquitetura Comum de Barramento de Objeto (CORBA) .......................................... 15
2.3.1 Object Management Group (OMG) .............................................................................. 15
2.3.2 Arquitetura Comum de Barramento de Objeto ......................................................... 16
2.3.3 ORA (Object Request Architecture) ........................................................................... 16
2.3.4 ORB (Object Request Broker) ..................................................................................... 16
2.3.5 Interface ORB ................................................................................................................ 16
2.3.6 DII (Dynamic invocation interface) ............................................................................. 17
2.3.7 DSI (Dynamic skeleton interface) ................................................................................ 17
2.3.8 Stub ................................................................................................................................. 17
2.3.9 Skeleton .......................................................................................................................... 18
2.3.10 Arquitetura de Gerenciamento de Objeto................................................................. 18
2.3.11 Integração utilizando CORBA ................................................................................... 19
2.3.12 Estudo de caso de integração utilizando CORBA .................................................... 21
2.4 Arquitetura Orientada a Serviço (SOA) ........................................................................ 23
2.4.1 Web Service.................................................................................................................... 24
2.4.2 Descrição de Serviços .................................................................................................... 24
2.4.3 UDDI - Descoberta e descrição de serviços ................................................................. 24
2.5 Breve análise de tecnologias de integração..................................................................... 25
2.5.1 CORBA e Web Service ................................................................................................. 25
3 TECNOLOGIAS - BAIXA PLATAFORMA ................................................................... 27
3.1 ICP Brasil .......................................................................................................................... 27
3.2 Certificado Digital ............................................................................................................ 28
3.3 Nota fiscal eletrônica (NF-e) estudo de Caso ................................................................. 30
3.3.1 Lei e objetivo do projeto ............................................................................................... 30
3.3.2 Conceito da nota fiscal eletrônica ................................................................................ 31
3.3.3 O ambiente virtual da secretaria da fazenda (SEFAZ) ............................................. 31
3.4 Web Service disponíveis no ambiente virtual da SEFAZ ............................................. 34
3.4.1 Descrição da recepção da NF-e .................................................................................... 34
3.5 Tecnologias para a aplicação desktop............................................................................. 35
3.5.1 J2EE................................................................................................................................ 35
3.5.2 XML................................................................................................................................ 35
4 TECNOLOGIAS - ALTA PLATAFORMA ..................................................................... 36
4.1 IBM Websphere MQ ........................................................................................................ 36
4.2 IBM Websphere MQ Client ............................................................................................ 36
4.3 IBM CICS TS3.2............................................................................................................... 37
 x

4.4 COBOL.............................................................................................................................. 37
4.5 DB2..................................................................................................................................... 38
4.6 Rational for System Z .................................................................................................. 38
5 IMPLEMENTAÇÃO DO PROTÓTIPO .......................................................................... 41
5 .1 Arquitetura de integração ............................................................................................ 41
5.1.1 Arquitetura de comunicação da camada Desktop ..................................................... 41
5.1.2 Arquitetura de comunicação da camada mainframe................................................. 42
5.2 Projeto e implementação do protótipo............................................................................ 43
5.2.1 Aplicação desktop .......................................................................................................... 43
5.2.2 Aplicação mainframe .................................................................................................... 48
6 CONCLUSÕES.................................................................................................................... 50
6.1 Contribuições e Conclusões ............................................................................................. 50
6.2 Trabalhos Futuros ............................................................................................................ 51
 11

1. INTRODUÇÃO

1.1 Motivação

O período de 50 a 80 é marcado pela computação centralizada. A característica dos

computadores construídos nesta época são super computadores e mainframes dotados de alto
poder de processamento. A utilização desta tecnologia justificava as atividades desenvolvidas
em universidades, centros militares, financeiros e governamentais. Esta modalidade de
computação ainda é utilizada pelas organizações. Sua utilização é justificada pela capacidade
que estes sistemas têm de trabalhar com dados críticos e servir a uma alta demanda de
processamento. Outro fator importante são as questões ligadas a escalabilidade e
extensibilidade, pois é possível aumentar a capacidade de processamento dos mainframes sem
a necessidade de paradas no sistema, mantendo-o disponível.

Entretanto o constante avanço da micro-eletrônica tornou viável a proposta de um modelo de

arquitetura compacta, com menor poder de processamento e baixo custo (THACKER, 1979).
Seu intuito era substituir o uso dos mainframes em tarefas que não necessitassem de alto
poder de processamento. O IBM-PC caracterizou-se por criar uma nova modalidade de
computação. As conseqüências deste desenvolvimento possibilitaram difundir a tecnologia do
computador pessoal (THACKER, 1979).

Com a expansão das redes de computadores e da Internet houve a necessidade de integrar

estas duas modalidades de computação, a centralizada com a distribuída. Isto se justifica
devido à necessidade do mercado, pois as organizações têm tecnologias robustas com alto
poder de processamento e que precisam ser disponibilizadas para computadores pessoais.

A nota fiscal eletrônica é um projeto do governo Federal que se desenvolve em parceria com
os governos estaduais e possui como objetivo regulamentar, padronizar a emissão de notas
fiscais em formato eletrônico (ENATE, 2011).

Atualmente várias empresas no mercado fornecem solução de nota fiscal eletrônica para os
mais diferenciados estabelecimentos. As características destas soluções, entretanto, variam
 12

entre aplicações desktop, que são voltadas para usuários de pequeno porte ou aplicações web,
para usuários de médio porte. Todas elas se conectando aos Web Services da secretaria da
fazenda para a transmissão da nota fiscal.

O presente trabalho propõe uma arquitetura de integração de software entre a baixa e a alta
plataforma. Como estudo de caso é desenvolvida uma aplicação desktop que se integre a um
componente de software disponível no ambiente mainframe. O componente de software
desenvolvido para a alta plataforma é capaz de gerenciar simultaneamente a requisição de
envio de nota fiscal eletrônica de vários usuários aos servidores da secretaria da fazenda.

Acredita-se que esta arquitetura possa suprir a necessidade tanto de usuários de pequeno porte
a usuários de grande porte.

1.2 Objetivos

1.2.1 Objetivo geral

Desenvolver uma solução de nota fiscal desktop que se integre a um

componente de mainframe utilizando IBM Websphere MQ para o posterior envio da nota
fiscal aos servidores da secretaria da fazenda.

1.2.2 Objetivos específicos

a)Desenvolver uma aplicação desktop Java para o envio de nota fiscal

eletrônica.

b)Desenvolver uma aplicação de alta plataforma utilizando IBM Websphere

MQ para receber uma nota fiscal eletrônica enviada pela aplicação desktop.

c)Integrar a aplicação de alta plataforma com a aplicação desktop.

 13

d)Integrar a aplicação de alta plataforma com o Web Service da secretaria da

fazenda do estado de São Paulo.

1.3 Metodologia

A metodologia aplicada aqui consiste na pesquisa e desenvolvimento de uma arquitetura entre

desktop e mainframe adotando-se a Nota Fiscal Eletrônica (NFE) como estudo de caso.

Para a realização desta pesquisa foi realizado um levantamento bibliográfico sobre duas
tecnologias de integração utilizadas no mercado, CORBA e Web Service. Este levantamento
bibliográfico colaborou na escolha da tecnologia mais apropriada para o problema da
integração entre sistemas distintos.

Posteriormente, foi realizado um levantamento das tecnologias para o desenvolvimento do

protótipo de envio de nota fiscal eletrônica desktop e do componente de software de envio do
xml da nota fiscal eletrônica para a SEFAZ que foi desenvolvido para o ambiente mainframe.

Foi feita a modelagem da arquitetura de integração. A partir da aplicação desktop foi criada
uma estrutura de conexão com o middleware IBM Websphere MQ, cuja principal
característica é o recurso de filas de mensagens. Esta aplicação desktop que foi desenvolvida
tem como principais funcionalidades a alimentação e o consumo destas filas de mensagens
através da ação de upload de um xml de uma nota fiscal eletrônica preenchida e assinada e da
leitura das respostas que são enviadas pelos Web Services da SEFAZ.

Para a implementação do protótipo desktop foi utilizado à linguagem de programação Java, a

biblioteca gráfica Java Swing e as bibliotecas do IBM Websphere MQ Client para a criação
da conexão com as filas de mensagens do IBM Websphere MQ.

A implementação do componente no mainframe compreende a utilização do IBM Websphere

MQ para a definição das filas de mensagem e o seu gerenciamento. O CICS (CICS –
Customer Information Control System) foi utilizado para a implementação do Web Service da
SEFAZ para que a nota fiscal eletrônica enviada da aplicação desktop possa chegar aos
servidores da Receita Federal por intermédio deste componente no mainframe. Além disso, o
 14

CICS alimenta as filas de mensagens com as respostas da SEFAZ de cada nota fiscal
eletrônica emitida na aplicação desktop.

1.4 Organização do trabalho

Este Trabalho está organizado da seguinte forma:

O capítulo 2 aborda à integração de baixa e alta plataforma, suas características e um histórico

contendo as definições de ambas as plataformas. Também é realizado um breve comparativo
entre as tecnologias SOA e CORBA abordando os seus principais conceitos e arquitetura.

O capítulo 3 apresenta algumas características das tecnologias de baixa plataforma utilizadas

para o desenvolvimento do protótipo. O capítulo apresenta as seguintes tecnologias: Java
Enterprise Edition (J2EE), Extendible Markup Language (XML) e certificado digital.

O capítulo 4 apresenta as ferramentas e tecnologias utilizadas durante o desenvolvimento do

protótipo na alta plataforma. No capítulo são apresentadas algumas características e
funcionalidades das ferramentas WebSphere MQ, Monitor de Transação CICS, COBOL e
DB2.

O capítulo 5 trata do desenvolvimento da solução de integração, da definição do modelo do

protótipo no ambiente mainframe e da interface do protótipo na baixa plataforma. É
apresentada a forma de integração utilizando Web Service. O capítulo também apresenta o
diagrama de classe, alguns casos de uso, o levantamento de requisitos funcionais e não
funcionais da solução, o modelo relacional e uma análise da aplicação e do sistema em ambas
as arquiteturas.

O capítulo 6 apresenta às considerações finais, experiências e resultados obtidos e sugestões

para trabalhos futuros.
 15

2 INTEGRAÇÃO DE BAIXA COM ALTA PLATAFORMA

2.1 Baixa plataforma

Baixa plataforma é como se denomina a modalidade de computação constituída por

microcomputadores. O objetivo dos microcomputadores era substituir o uso de computadores
de grande porte em atividades que não necessitassem alto poder de processamento. A idéia era
criar uma máquina menor, de baixo custo e que tivesse capacidade suficiente para satisfazer
as necessidades de um único usuário (THACKER, 1979).

A popularização do computador pessoal possibilitou o desenvolvimento de aplicações para as

mais diversas finalidades. Seu uso, atualmente é imprescindível para a execução do trabalho
de vários profissionais nos mais variados segmentos do mercado de trabalho.

2.2 Alta Plataforma

O termo mainframe é utilizado para se referir a computadores desenhados com o objetivo de

processar cargas muito grandes de dados e servir a milhares de usuários. Seu uso é voltado
tipicamente para grandes empresas que possuem aplicações críticas (THECHTERMS, 2010).
A presença do mainframe está relacionada ao conceito de computação centralizada, seu uso
em grandes corporações é justificado, pois o mainframe torna-se um repositório central de
dados que está conectado a dispositivos menores como terminais e estações de trabalho.

2.3 Arquitetura Comum de Barramento de Objeto (CORBA)

As seções seguintes explicam a arquitetura CORBA e sua integração com outras plataformas.

2.3.1 Object Management Group (OMG)

O Grupo de Gerenciamento de Objeto (OMG - Object Management Group) é uma

organização internacional sem fins lucrativos. Foi fundada em 1984 e possui em torno de 750
empresas que ajudam no desenvolvimento do projeto. Entre estas empresas estão IBM, HP,
SUN, DEC, Microsoft. O objetivo é definir padrões para aplicações orientadas a objetos
 16

distribuídos, com a finalidade de atender a indústria de desenvolvimento de software. O

padrão de integração proposto pela OMG foi a Arquitetura de Gerenciamento de Objeto
(OMA - Object Management Architecture) (OMG, 2010).

2.3.2 Arquitetura Comum de Barramento de Objeto

A Arquitetura Comum de Barramento de Objeto (CORBA - Common Object Request Broker

Architecture) foi desenvolvida pela OMG e suas empresas membro para estabelecer padrões e
simplificar a troca de dados entre objetos em sistemas heterogêneos distribuídos (OMG,
2010).

2.3.3 ORA (Object Request Architecture)

O ORA exerce o papel de middleware entre os objetos distribuídos. É responsável também

pela comunicação entre objetos de forma transparente, entre o cliente e a implementações dos
objetos desejados (OMG, 2010).

2.3.4 ORB (Object Request Broker)

O ORB é responsável pela comunicação e interação entre os objetos distribuídos e um dos

principais simplificadores na hora de desenvolver em ambientes distribuídos, sendo que o
mesmo trata características de baixo nível da implementação, ele intercepta a chamada e fica
responsável por definir um objeto que atenda a solicitação do objeto solicitante. Ao encontrar
o objeto que atenda a necessidade o ORB passa a esses objetos os parâmetro do objeto
solicitante, por sua ver o objeto solicitado processa os parâmetros e devolve a resposta ORB,
que transmite ao objeto solicitante. Dessa maneira o usuário não precisa preocupar-se onde o
objeto está, ou em que sistema operacional o mesmo se encontra ou qual programa foi usado
para desenvolvê-lo (OMG, 2010).

2.3.5 Interface ORB

A Interface ORB foi definida, dentro da especificação do CORBA, como uma "interface
abstrata" para o ORB, servido como uma biblioteca de ajuda para a implementação de
 17

serviços locais dentro o ORB. Onde ainda, por esta interface se tratar de uma entidade lógica,
pode ser implementada de diversas maneiras, portanto, a interface ORB vem justamente com
o intuito de desacoplar as aplicações dos detalhes de cada uma dessas implementações na
camada ORB. Dentre as funcionalidades oferecidas por essa interface, temos a conversão de
“referências a objetos” para strings e vice-versa, provê também a criação de listas de
argumentos para as requisições que são realizadas através da interface de invocação dinâmica
(OMG, 2010).

2.3.6 DII (Dynamic invocation interface)

É um canal de comunicação implementado no lado do cliente. Permite ao mesmo, por meio

das tentativas de implementação dos métodos em tempo de execução, um acesso direto aos
mecanismos de requisição residentes em um ORB e também que realizem uma sincronização
entre os objetos remotos, conhecidos como deferidas ou não-bloqueadas (operações separadas
de envio e recebimento) e chamadas unidirecionais (só de envio). Neste tipo de invocação,
esse processo é feito de forma dinâmica sem necessitar passar pela interface específica da IDL
para que seja ativado (OMG, 2010).

2.3.7 DSI (Dynamic skeleton interface)

O DSI realiza uma função semelhante à realizada pela DII, a diferença básica, é que todas as
atividades realizadas pela DSI são feitas no servidor. A principal característica da DSI é
permitir que ORB transmita, apesar de não conhecer em tempo de execução o tipo de objeto
utilizado, requisições para uma implementação de objeto, correlacionado diretamente com o
Skeleton (OMG, 2010).

2.3.8 Stub

Está localizado no cliente, tem como característica promover interfaces estáticas para criar e
enviar requisições correspondentes dos serviços desejados do cliente para o servidor. O Stub é
criado utilizando-se um compilador IDL e está implementado diretamente do lado do cliente
(OMG, 2010).
 18

2.3.9 Skeleton

Está vinculado diretamente com o Stub e tem como função fornecer a interface através da
qual o método recebe as requisições. Está implementado diretamente do lado do servidor
(OMG, 2010).

2.3.10 Arquitetura de Gerenciamento de Objeto

A Arquitetura de Gerenciamento de Objeto (OMA - Object Management Architecture) é um

padrão de arquitetura, desenvolvido pela OMG, uma tecnologia de middleware que é utilizado
para mover ou transportar informações, dados de sistemas heterogêneos com diversos
protocolos de rede e sistemas operacionais. Independente de plataforma o padrão OMA é
constituído por interfaces de alto nível conhecidas como Interface de programação de
Aplicação (API – Application Programming Interface), possui os seguintes objetivos de
integrar objetos de sistemas distribuídos, fornecer orientação sobre a padronização de
interface, desenvolver a criação de componentes que permitam integrar um ou mais objetos
que tenham funcionalidades comuns e disponibilizá-lo por meio de interfaces de comunicação
entre objetos (OMG, 2010). Este padrão é dividido em módulos e componentes de serviço que
serão tratados abaixo, padrão de arquitetura OMA ilustrado na Figura 1.
 19

Figura 1 - Infra-estrutura dos componentes CORBA.

Adaptado de: OMG, 2010.

2.3.11 Integração utilizando CORBA

As necessidades de integração das diversas plataformas que se encontram no ambiente de

negócio são das mais variadas. Desde instituições financeiras como bancos até órgãos
governamentais possuem plataformas mistas em funcionamento, que precisam acessar
recursos e processos entre diversas aplicações existentes, entretanto são sistemas legados e
críticos para o negocio. Isto implica que devido à natureza deste ambiente não é aconselhável
a substituição de tecnologia devido ao custo e riscos envolvidos, porém, uma das soluções
plausíveis para a integração de plataformas distintas está contida no universo dos objetos
distribuídos, o mesmo visa estabelecer uma comunicação entre esses ambientes mistos,
independente da plataforma ou arquitetura utilizada, simplificar a manutenção e o
desenvolvimento de objetos e sistemas, propondo o reuso de objetos comuns aos diversos
tipos de aplicações, dispostas neste ambiente. Sabe-se que este ambiente tem por
característica ser composto por arquiteturas de hardware e software mistas. Englobam
aplicativos em diversas linguagens de programação e uma variedade de Sistemas
 20

Operacionais (SO) envolvidos, além de variações entre diversos protocolos de rede. Portanto
este ambiente torna-se heterogêneo e de alta complexidade (BALBINO, 2010).

Devido à evolução da micro-informática e o aumento na capacidade de processamento bem

como o aprimoramento da arquitetura dos PC’s possibilitou que os sistemas centralizados
fossem migrados para sistemas distribuídos, houve algumas implicações devido à
complexidade da arquitetura distribuída, geralmente o desenvolvimento de soluções nesta
arquitetura são em suma mais complexas e demandam mais tempo para desenvolvimento.
Também há dificuldades relacionadas a distribuição do processamento em diversos pontos de
uma rede e o paralelismo de processamento envolvido (BALBINO, 2010).

Para efetuar a comunicação entre objetos distintos dentro de uma arquitetura distribuída,
existem varias maneiras de fazê-lo, sendo que os objetos podem comunicar-se tanto
internamente, utilizando ambientes compartilhados de memória do aplicativo bem como se
comunicar com outros objetos dispostos em maquinas diferentes. Para efetuar tal processo o
objeto distribuído utiliza API’s, para efetuar passagem de mensagens e estabelecer
comunicação entre objetos às vezes implementado em plataformas distintas e tem como
recurso a utilização de protocolos de transporte (BALBINO, 2010).

A utilização dos protocolos de transporte tem custos em complexidade ao codificar a solução,

devido a inúmeros processos de comunicação que envolve os protocolos de transporte, porém
o programador pode optar por métodos de comunicação encapsulados como o caso da
Invocação de Método Remoto (RMI – Remote Method Invocation) que abstrai a camada de
rede tornando a conexão uma tarefa simples como se o objeto que está sendo invocado
estivesse na própria maquina (BALBINO, 2010).

Com a crescente demanda por reuso de código os programadores que defendem o paradigma
orientado a objeto, investiram no desenvolvimento de soluções embasadas em componentes
que são um ou mais objetos integrados que sozinhos conseguem ser genéricos o suficiente
para serem utilizado em diversos sistemas. Para efetuarem a comunicação entre componentes
foram desenvolvidos alguns padrões para Windows, como por exemplo, o DCOM
(Distributed Component Object Model), para Java as tecnologias JavaBeans e Enterprise
JavaBeans, e uma arquitetura que é independente de plataforma chamada CORBA (Common
Object Request Broker Architecture) (BALBINO, 2010).
 21

O CORBA é um padrão desenvolvido sobre as especificações do padrão Barramento Comum

de Requisição de Objeto (ORB - Common Object Request Broker) e utilizado para efetuar a
conexão entre objetos que estão contidos em pontos diferentes de uma rede. Para efetuar essa
comunicação é utilizada uma linguagem de programação própria para implementar os Stubs
que são interfaces de acesso ao objeto remoto. Essa interface é compilada na linguagem nativa
do aplicativo cliente que irá utilizar o serviço. O mesmo acontece com outra estrutura
conhecida como Skeleton que é compilada na linguagem do aplicativo cliente. O Skeleton fica
disponível no servidor para disponibilizar a inteface com o aplicativo solicitado.

2.3.12 Estudo de caso de integração utilizando CORBA

A instituição Wells Fargo é citada como um dos oito experimentos descritos no livro 3 Tier
Client/Server At Work (EDWARDS, 1997). O livro trata de tecnologias para a integração de
plataformas distintas. Neste estudo de caso foi utilizada a tecnologia CORBA para efetuar a
integração (BALBINO, 2010).

Na década de 80, nos Estados Unidos, os bancos passaram a oferecer a seus clientes uma
gama de serviços que não faziam parte dos serviços tradicionalmente oferecidos por um
banco. Seus clientes recebiam diferentes extratos para cada produto que era comercializado
pelo banco (RONAYNE, 1996). Porém no final da mesma década a crescente tendência era
que diversos tipos de extratos fossem substituídos por apenas um extrato que reunisse
informações de todos os produtos que o cliente pudesse ter, este extrato ficou conhecido como
compound statement banking (RONAYNE, 1996). Os bancos começaram a integrar seus
extratos de diversos tipos de contas como conta corrente, conta poupança, hipotecas, cartões
de crédito, corretagem e contas para aposentadoria para a obtenção de um único extrato
(BALBINO, 2010).

A instituição Wells Fargo, enfrentava a limitação a esse tipo de exigência do mercado, por
suas contas estarem alocadas em plataformas distintas como IBM MVSq/CICS, Digital
VAX/VMS e UNIX, possibilitando um ambiente propício para a aplicação da tecnologia
CORBA, para solução da dificuldade (BALBINO, 2010).
 22

Tendo em vista esse ambiente de plataformas mista foi criado uma solução de integração
baseada na tecnologia CORBA, que propunha a integração entre os diversos tipos de conta
por meio de um Sistema de Relacionamento com Cliente (CRS - Customer Relationship
System) que utilizava o ORB da empresa BEA utilizando servidores com Barramento de
Objeto. Esse sistema propunha uma integração lógica das contas por novo conceito de seguro
social um único número capaz de unificar todas as contas do Número de Seguridade Social
(SSN - Social Security Number) para pessoas físicas e o Número de Identificação do
Empregador (EIN - Employer Identification Number) para as pessoas jurídicas (BALBINO,
2010).

A Integração nesse ambiente foi realizada com sucesso entre as plataformas HP 9000 (HP-
UX), computadores pessoais (Windows) e Sun (SunOs), porém com os mainframes IBM foi
diferente, pois em 1993 não havia suporte para ORB. Para mainframe a integração foi
efetuada através de meios não CORBA, veja Figura 2.

Figura 2 - Ambientes integrados utilizando o Object Broker do CORBA.

Fonte: RONAYNE, 1996.
 23

2.4 Arquitetura Orientada a Serviço (SOA)

Arquitetura Orientada a Serviço (SOA - Service Oriented Architecture) tem como base
disponibilizar o produto de processamento de uma determinada aplicação, por meio de serviço
estabelecendo contratos de comunicações entre as diversas aplicações existentes, baseando-se
em um principio de computação distribuída (SOMMERVILLE, 2006). O objetivo desta
arquitetura é disponibilizar funcionalidades de uma aplicação na forma de serviço através dos
conceitos-chave de application frontend, repositório de serviço e barramento de serviço
(MARINHO, 2006).

O application frontend é uma entidade responsável por interagir, enviando e recebendo

resposta de outros elementos de software tais como aplicações web, interfaces gráficas ou até
mesmo sistemas batch.

O repositório de serviço dispõe de facilidades para o descobrimento de serviços disponíveis

na arquitetura como, por exemplo, a localização virtual, provedor, taxas, limitações técnicas,
aspectos de segurança entre outros.

O barramento de serviço é a entidade utilizada para conexão entre todos os participantes da

SOA.

Algum dos aspectos arquiteturais que SOA prove no ambiente de negocio de uma instituição
como modularidade, reuso e encapsulamento (IBM, 2010). Uma das modalidades de SOA é
dada por meio da implementação de um web service, utilizando um contrato de comunicação
possível graças à implementação de padrões estabelecidos para a troca de mensagem entre
web service para estabelecer a comunicação entre eles. Entre esses padrões se encontra o
SOAP (Simple Object Access Protocol) que utiliza XML para efetuar a troca de mensagens
entre aplicações e o REST (Representational State Transfer) que utiliza protocolo HTTP
(Hypertext Transfer Protocol) e XML (Extensible Markup Language) para efetuar a troca de
mensagens entre aplicações (SOAP, 2010).
 24

A arquitetura SOA terá grande influência no processo de desenvolvimento dos sistemas de

informação estima-se que até 2008 haverá 70% de probabilidade do uso de SOA como prática
predominante de engenharia de software (MCCOY, 2003).

2.4.1 Web Service

Web Service é um termo utilizado para o componente de software que transmite dados no
formato XML para outros sistemas. Utilizando Web Service uma aplicação pode invocar um
serviço disponível em outra aplicação para efetuar uma tarefa integrando sistemas permitindo
sua interação independente de plataforma e linguagem de programação (SOMMERVILLE,
2006).

O Web Service é composto por três tecnologias o Protocolo de Acesso a Objeto Simples
(SOAP - Simple Object Access Protocol), a Linguagem de Descrição de Web Service (WSDL
- Web Service Description Language) e o Descritor Universal de Descoberta e Integração
(UDDI - Universal Description Discovery and Integration).

2.4.2 Descrição de Serviços

A Linguagem de Descrição de um Web Service (WSDL) faz uso de um arquivo XML para
descrever as características e comportamentos de Web Service. Algumas características são:
como o que o Web Service pode fazer, o servidor do Web Service e a forma como ele é
invocado.

2.4.3 UDDI - Descoberta e descrição de serviços

O UDDI é um contrato que define um padrão XML para que os Web Service sejam
descobertos por serviços de busca.
 25

O padrão UDDI é reconhecido pela OASIS (Organization for the Advancement of Structured
Information Standards). A OASIS é uma organização sem fins lucrativos que conduz o
desenvolvimento e a adoção de padrões abertos para tecnologia da informação (OASIS,
2011). O UDDI é um serviço de registros de Web Service, sua finalidade é representar
metadados de serviços através de um padrão permitindo assim criar catálogos.

2.5 Breve análise de tecnologias de integração

Esta seção é dedicada a uma breve análise das tecnologias de integração.

2.5.1 CORBA e Web Service

CORBA é um padrão desenvolvido para permitir a criação de aplicações com objetos

distribuídos (OMG, 2010). Os Web Services são um padrão desenvolvido para disponibilizar
pequenos serviços no formato de procedimento remoto (SOAP, 2010).

A Tabela 1 expõe as vantagens e desvantagens da utilização de Web Service e suas

implicações.

Tabela 1 - Vantagens e desvantagens da utilização de Web Service.

Fonte: (SOAP, 2010).

Vantagens Desvantagens
O Web Service é transparente do ponto de Em comparação com as chamadas RPC
vista do protocolo de comunicação entre existentes o protocolo SOAP, apresenta
cliente e o servidor. uma menor eficiência.
Os Web Services utilizam um protocolo A troca efetuada entre sistema RPC é pelo
chamado SOAP, baseado em XML de fácil formato binário sendo que a troca de
leitura e fácil programação. mensagens pelo protocolo SOAP e dada por
arquivo XML apresentando um menor
desempenho.
O protocolo SOAP atua sobre o protocolo Outro ponto agravante é a escolha do
 26

HTTP, sendo, portanto transparente no protocolo de comunicação entre Web

ponto para os firewalls. Service, se optarmos na arquitetura por
protocolos seguros como o SSL terá perda
em desempenho da aplicação em contra
partida se escolher protocolos simples com
o XML Signature teremos perdas efetivas
na segurança dessa informação.
A Tabela 2 expõe algumas vantagens e desvantagens da utilização de CORBA e suas
implicações.

Tabela 2 - Vantagens e desvantagens da utilização de CORBA.

Adaptado de: (OMG, 2010 ; BALBINO, 2010).

Vantagens Desvantagens
O CORBA é um padrão que tem o Não tem implementação da camada ORA
diferencial de permitir objetos distribuídos para ambiente mainframe.
e não apenas procedimentos distribuídos
O CORBA pode trabalhar com o A camada ORA está diretamente
protocolo de GIOP, que possui diversos relacionada à implementação do Stubs e
tipos de implementação como o IIOP (que Skeletons, são implementações de interface
constitui do protocolo GIOP sobre entre aplicativos cliente e servidores. Estas
TCP/IP) e o HTIOP (que constitui do interfaces ficam diretamente ligadas à
protocolo GIOP sobre HTTP), esse último linguagem que o aplicativo foi
têm uma função similar ao protocolo implementado.
SOAP/HTTP.

A independência de plataformas devido à Maior complexidade na implementação da

disponibilidade da camada IDL na solução por estar diretamente ligada à
tecnologia CORBA, um dos seus chamada de objetos distribuídos.
principais atrativos.
 27

3 TECNOLOGIAS - BAIXA PLATAFORMA

Este capítulo apresenta de forma objetiva as tecnologias utilizadas para o desenvolvimento do

protótipo.

3.1 ICP Brasil

A Infra-estrutura de Chave Pública (ICP) é um conjunto de regras que regulamenta a emissão

de chave pública no Brasil. Sendo que somente algumas entidades têm autorização para emitir
um certificado digital que tenha valor jurídico nos termos da Medida Provisória nº 2.200-2, de
24.8.2001 (MOREIRA, 2004). Esta infra-estrutura foi desenvolvida pelo Instituto Nacional de
Tecnologia da Informação (ITI)

A divisão hierárquica do ICP-Brasil é dada por AC (Autoridade Certificadora) que são

entidades publicas ou privadas que emitem, distribuem, revogam e gerenciam (MOREIRA,
2004). As ARs (Autoridade de Registro) são entidades responsáveis pela interface entre
usuário e autoridades certificadoras, pois facilitam o recebimento, validação, encaminhamento
de solicitações de emissão ou revogação de certificados digitais para as AC (ITI, 2010),
conforme a Figura 3.

Figura 3 - Estrutura geral da ICP-Brasil.

Fonte: ITI, 2010.

 28

3.2 Certificado Digital

Uma das tecnologias desenvolvidas pelo ITI é conhecida como certificado digital que por
meio de conceitos e técnicas computacionais como criptografia permite a criação de uma
assinatura digital garantindo aos documentos digitais, por exemplo, a nota fiscal eletrônica
aspectos como autenticidade, confidencialidade, integridade e não-repúdio de documentos e
transações comerciais (VERONESE, 2008).

A Autenticidade até então era restrita a documentos impressos e com reconhecimento de

firma, esse critério predispõe a identificação do emissor do documento permitindo a
conferencia caso seja necessária de quem emitiu a identificação da pessoa física ou jurídica
(VERONESE, 2008).

A confidencialidade de dados sigilosos, como dados pessoais e dados financeiros, tem suas
restrições de informação, destinada apenas ao emissor ou ao órgão responsável pela emissão
documento, para prevenção de fraudes e manipulação dessas informações. Antes dos adventos
digitais esses dados eram protegidos dentro de departamentos e ficavam restritos a pessoas
autorizadas. Hoje no caso de documentos digitais, esse requisito é feito por criptografia que
permite que o emissor da mensagem cifre a informação para que apenas o destinatário possa
compreendê-la, permitindo o sigilo entre dados confidenciais (ITI, 2010).

A integridade era efetuada por meio de não rasura e analise em documentos de identificação
para a validade da informação, garantindo que os dados fossem realmente pertinentes a pessoa
que os disponibilizavam, hoje esse processo acontece por meio de comparação feita por
algoritmos que testam o HASH de uma determinada informação para validar se não houve
alteração na mesma (ITI, 2010).

O não-repúdio é uma característica jurídica que da validade das informações contidas em um

documento e impele o receptor de negar a veracidade das informações contida naquele
documento. Uma de suas formas hoje utilizada é o reconhecimento de firma por um cartório
que garante a veracidade da informação ali inserida. Nos meios digitais, hoje esse processo é
feito por tecnologias com o uso do certificado digital, que possibilitam transações de
documentos na via digital, garantindo a veracidade das informações ali contidas
(VERONESE, 2008).
 29

O Certificado digital é um documento que permite armazenar em seu interior informações

como:
a) Chave pública
b) Nome e endereço de e-mail
c) Data de validade da chave pública
d) Identificação da Autoridade Certificadora
e) Número de série do Certificado Digital
f) Assinatura digital da Autoridade Certificadora (AC)

A Figura 4 mostra como estas informações ficam disponíveis para um usuário.

Figura 4 - Dados de Identificação do Certificado digital.

Fonte: Microsoft Windows XP, 2010.

Na aba detalhes é possível notar todas informações do certificado digital incluindo

informações técnicas e computacionais, conforme a Figura 5.
 30

Figura 5 - Todos os dados contidos no certificado digital, aba Detalhe

Fonte: Microsoft Windows XP, 2010.

3.3 Nota fiscal eletrônica (NF-e) estudo de Caso

As seções seguintes explicam de forma detalhada o funcionamento da NF-e.

3.3.1 Lei e objetivo do projeto

A nota fiscal eletrônica (NF-e) foi desenvolvida a partir da assinatura do protocolo de ENAT
03/2005 (27/08/2005). Este protocolo se baseou na lei complementar contida no Ato COTEPE
72/05, de 22/12/2005 (FAZENDA, 2011), a lei estabelece que:
a) A substituição dos antigos modelos fiscais 1 e A1 por um documento
auxiliar da NF-e (DANFE) com validade jurídica.
b) A validade jurídica dos documentos digitais e sigilo fiscal, por meio de
tecnologias como o certificado digital que permita a integridade,
confiabilidade, autenticidade e não repudio dos dados fiscais emitidos.
c) A Padronização no território nacional da NF-e, por meio de tecnologias
como o Web Service que possibilita os serviços de cancelamento, inutilização,
cadastro e consulta da NF-e (FAZENDA, 2011).
 31

3.3.2 Conceito da nota fiscal eletrônica

A NF-e tem por objetivo ser um documento de emissão restrita ao meio digital para produtos
e prestações de serviços, garantindo a autenticidade dos dados fiscais por meio da assinatura
eletrônica através do certificado digital. A seguir a listagem de algumas das vantagens da NF-
e (ENATE, 2011):
a) Redução da burocracia agilizando o processo de recolhimento de
impostos.
b) Melhor acesso das informações por parte do fisco.
c) Proposta de uma arquitetura altamente segura e com recursos
computacionais que garanta disponibilidade e elevado desempenho no acesso
as informações.
d) Viabilizar o acesso à maior número de contribuintes para o
recolhimento de impostos.
e) Favorecer a um ambiente único da secretaria da fazenda e a
centralização das informações em um único sistema digital nacional (ENATE,
2011).

3.3.3 O ambiente virtual da secretaria da fazenda (SEFAZ)

O ambiente da SEFAZ foi proposto para garantir um ambiente seguro com alta
disponibilidade e elevado desempenho computacional. Esse ambiente tem por objetivo
receber documentos digitais emitidos via internet usando o Web Service da SEFAZ. Este
documento digital é conhecido como NF-e (RECEITA, 2011).

O Web Service da SEFAZ promove o encapsulamento da lógica de negócio da NF-e. Os

padrões SOAP e XML são utilizados para possibilitar a comunicação de sistemas
heterogêneos com o ambiente virtual possibilitando assim a independência de plataforma
(CERAMI, 2002).
 32

Após a emissão da NF-e para o ambiente virtual o Web Service da SEFAZ envia uma
resposta de rejeição ou autorização para o uso desta NF-e (RECEITA, 2011). A Figura 6
mostra o esquema de funcionamento do ambiente virtual da SEFAZ.
A arquitetura de serviços da SEFAZ virtual prevê os seguintes ambientes:
a) Homologação – ambiente de teste sem validade jurídica disponibilizada
pela receita.
b) Produção – ambiente normal de faturamento da receita, o mesmo
garante toda a validade legal dos dados nele faturado.
c) Contingência – ambiente de contingência para casos de queda do
ambiente de produção ou algum problema técnico que inviabilize o envio de
NF-e para a receita (RECEITA, 2011).
 SEFAZ

Ambiente SPED

SEFAZ Virtual
Web Farm
NF-e
...
Contribuinte
Serv Serv Serv Serv NF-e
SEFAZ
- Recepção, Validação e Autorização da
NF-e NF-e
INTERNET INTERNET
Ambiente Nacional

NF-e
- Recepção e Armazenamento da NF-e
Geração de NF-e
Consulta resultado

Fonte: SEFAZ adaptado, 2011.

NF-e
Portal SUFRAMA
http://www.nfe.fazenda.gov.br/portal

Figura 6 – Funcionamento da SEFAZ virtual.

- Consulta NF-e
33
 34

3.4 Web Service disponíveis no ambiente virtual da SEFAZ

Esta seção descreve os principais Web Services oferecidos pelo ambiente virtual da SEFAZ.
O serviço de recepção da NF-e será abordado com maior ênfase, pois será usado como
exemplo no protótipo.

3.4.1 Descrição da recepção da NF-e

A recepção de nota fiscal consiste no seguinte processo, o contribuinte efetua o envio de uma
NF-e já preenchida e assinada pelo certificado digital para o Web Service de nome
nfeRecepcaoLote da SEFAZ virtual. Após a requisição deste serviço a SEFAZ processa a NF-
e e devolve uma resposta no formato XML ao contribuinte. É possível obter as seguintes
respostas:
a) Rejeição – A resposta de rejeição é dada quando há algum problema de
preenchimento dos campos do XML.
b) Erro de XML – A resposta de erro é dado quando há falha de schema de
XML
c) Autorização – A resposta de autorização é dada quando não existe
nenhuma falha de schema de XML e quando não existe erro de preenchimento
dos campos
A Figura 7 mostra o fluxo de envio de uma NF-e ao ambiente virtual da SEFAZ

Contribuinte SEFAZ
Web Service:
NfeRecepcao Filas de entrada
Envio do lote
da NF-e nfeRecepcaoLote Processamento
Cliente NF-e
Aplicação
NF-e
Recibo

Figura 7 – Processo de envioda NF-e ao ambiente virtual da SEFAZ.

Fonte: RECEITA adaptado, 2010.

 35

3.5 Tecnologias para a aplicação desktop

Este seção aborda as tecnologias utilizadas na baixa plataforma para o desenvolvimento da

solução de integração. Será feita uma breve descrição das tecnologias e suas respectivas
origens.

3.5.1 J2EE

O Java edição empresarial (J2EE - Java to Enterprise Edition) é uma edição diferente da
edição Java Edição Padrão (JSE - Java Standard Edition). A plataforma J2EE é um ambiente
para desenvolvimento e distribuição de aplicações empresariais. Consiste de um conjunto de
serviços, interfaces de programação de aplicação (API) e protocolos que provêem
funcionalidades para desenvolvimento de aplicações multi-thread, tolerante a falhas, multi-
camada e aplicações baseadas em componentes modulares executando em um servidor de
aplicações Web (SUN, 2010).

3.5.2 XML

Linguagem de marcação extensível (XML) é um arquivo de formato texto simples para

representar uma informação estruturada como documentos, dados, configurações, livros,
transações entre outros. Seu padrão é derivado de um formato chamado SGML (W3C, 2010).

O XML é um dos formatos mais utilizados para compartilhar informação estruturada entre
programas, pessoas, computadores, tanto localmente quanto através da internet. O formato
XML é muito parecido com o formato HTML. O formato XML tem várias vantagens em
cima de outros formatos como:
a) Redundância
b) Autodescritivo
c) Portabilidade
 36

4 TECNOLOGIAS - ALTA PLATAFORMA

Neste capítulo serão apresentadas as principais características das ferramentas existentes no

ambiente mainframe que utilizadas para o desenvolvimento de uma parte do protótipo
responsável por se comunicar com a aplicação desktop. Dentre estas ferramentas foram
selecionadas IBM Websphere MQ, IBM Websphere MQ Client, IBM CICS TS3.1, COBOL e
DB2.

Estas ferramentas foram escolhidas, pois são ferramentas que disponibilizam as

funcionalidades básicas para o conceito de integração utilizando SOA na alta plataforma.

4.1 IBM Websphere MQ

IBM Websphere MQ (WMQ) é uma plataforma middleware que utiliza um modelo de

transporte assíncrono de dados desenvolvido pela IBM. Este middleware é utilizado para
transportar dados assegurando a entrega de mensagens utilizando uma API que suporta uma
variedade de linguagens de programação. Sua arquitetura é baseada em fila de mensagens que
se conectam com as mais variadas plataformas de hardware e sistemas operacionais
(RAYNS).

4.2 IBM Websphere MQ Client

Websphere MQ Client é um componente do Websphere MQ que pode ser instalado em

ambientes que não exista um gerenciador de fila sendo executado. A aplicação permite que
outra aplicação se conecte a um gerenciador de fila e faça chamadas de comandos da API do
WMQ como, por exemplo, a inserção e leitura de mensagens nas filas de mensagens que estão
sendo executados em outro ambiente. A comunicação entre cliente e servidor é feita
utilizando um canal de comunicação chamado MQI, este canal é responsável por manter a
conexão ativa entre cliente e servidor. A Figura 8 a conexão de uma aplicação que utiliza
WMQ (WMQC, 2010).
 37

Figura 8 - Canal de comunicação cliente servidor de uma aplicação WMQ.

Fonte: WMQC, 2010.

4.3 IBM CICS TS3.2

CICS é um poderoso monitor de transação responsável por processar milhares de requisições

em mainframes IBM. Suporta um grande volume de transações oferecendo um tempo rápido
de resposta. É utilizado tanto em pequenas aplicações quanto em grandes aplicações
empresarias como softwares voltados para bancos (IBM, 2010).

O CICS possuí várias características relacionadas a ambientes de transação como

gerenciamento de concorrência, compartilhamento de recursos, integridade de dados,
priorização de trabalho, suporte para aplicações de escritas em linguagens como COBOL, C,
C++, PL/I, Java e Assembler. Possuí também interoperabilidade com o IBM Websphere MQ.

4.4 COBOL

Cobol é uma linguagem de programação de alto nível desenvolvida primeiramente em 1960

por uma conferência chamada CODASYL Committee (Conference on Data Systems
Languages). A responsabilidade de desenvolver novos padrões da linguagem foi assumida
pela ANSI(American National Standards Institute) que produziu outros três padrões da
linguagem nos anos de 1968, 1974 e 1985. A palavra COBOL é o acrônimo de Common
Bussiness Oriented Language. A linguagem é voltada para aplicações de negócios,
principalmente para processamento de arquivos. Sua estrutura contém palavras oriundas da
 38

língua inglesa, o principal objetivo é possibilitar que qualquer pessoa que não fosse
programador pudesse ler um código em COBOL. O COBOL é uma linguagem simples que
não contém ponteiros, não existe funções definidas por usuários e não têm tipos definidos por
usuários, não é uma linguagem proprietária, portável para várias plataformas (CSIS, 2010).

A linguagem COBOL tem sido uma das linguagens mais utilizadas nos negócios. Em um
relatório publicado pelo grupo Gartner estimou-se que em 1997 existiam em torno de 240
bilhões de linhas de código escritas em COBOL no mundo (BROWN, 2010) e que 50% das
aplicações de missão crítica em 1999 eram desenvolvidas em COBOL.
Aplicações feitas em COBOL são caracterizadas de longa duração, freqüentemente
executadas em área críticas de negócios como bancos e instituições governamentais. Em torno
de 95% dos dados de bancos são processados com COBOL.

4.5 DB2

DB2 é um sistema gerenciador de banco de dados (SGBD) relacional desenvolvido pela IBM
que primeiramente rodava em sistemas Unix, mainframes e plataformas AS/400.
O DB2 foi o primeiro banco de dados desenvolvido a utilizar a teoria do banco de dados
relacional que foi desenvolvida por E.F. Codd. Codd enquanto membro da IBM publicou sua
teoria em junho de 1970, junto com sua teoria Codd desenvolveu uma linguagem para
manipular dados ralacionais que mais tarde foi chamada de SQL (WATTERSON, 2010).

O DB2 pode ser administrado tanto em linha de comando quanto em interface gráfica, possui
também APIs para várias linguagens de programação como REXX, PL/I, COBOL,
FORTRAN, C++, C Java e várias outras linguagens.

4.6 Rational for System Z

O IBM Rational Development for System Z (RDZ) é um ambiente de desenvolvimento

integrado (IDE – Integrated Development Enviroment) com foco em aplicações voltadas para
mainframe. Com o RDZ é possível desenvolver aplicações nas mais dirversas linguagens para
mainframe como: COBOL, PL/I, C, C++, Assembler, JCL, REXX e Java (RATIONAL,
2010).
 39

Sua interface permite a simples interação com os subsistemas que são executados no
mainframe como CICS, IMS, DB2, Operações de controle do Lote, Z/OS Unix e os ambientes
de transação Websphere. A Figura 9 mostra a interface do RDZ (RATIONAL, 2010).
 40

Figura 9 – Exemplo código COBOL com RDZ.

Fonte: RATIONAL, 2010.

 41

5 IMPLEMENTAÇÃO DO PROTÓTIPO

Este capítulo irá aborda os detalhes de implementação do protótipo emissor de nota fiscal
eletrônica, detalhando suas funcionalidades e o fluxo de dados realizado pela nota eletrônica
na arquitetura proposta.

O protótipo será apresentado da seguinte forma: Arquitetura de integração e Protótipo do

Sistema.

5.1 Arquitetura de integração

Esta seção demonstrará de forma detalhada como as ferramentas descritas no capítulo 4 serão
utilizadas para construir a arquitetura responsável pela comunicação da aplicação desktop com
o mainframe.

A arquitetura de integração é dividida em 2 camadas para possibilitar o fluxo de uma

mensagem do emissor desktop de nota fiscal eletrônica para uma fila de mensagem do
mainframe.

5.1.1 Arquitetura de comunicação da camada Desktop

A estrutura construída no lado desktop compreende dois aplicativos, o emissor de nota fiscal
eletrônica e Websphere MQ Client.

O emissor de nota fiscal eletrônica é desenvolvido em Java Swing e é composta de duas

funcionalidades. A primeira funcionalidade se constitui do carregamento de uma nota fiscal
eletrônica preenchida no formato xml para dentro do emissor. A segunda funcionalidade é o
envio do arquivo em formato xml para uma fila de entrada de mensagens ao IBM Websphere
MQ no mainframe utilizando como intermediário desta conexão a API do aplicativo IBM
Websphere MQ Client. A Figura 10 ilustra como é feita a comunicação da plataforma desktop
com o mainframe para o envio de um arquivo xml.
 42

APLICAÇÃO DESKTOP MAINFRAME

Envio de mensagem Websphere MQ

Websphere MQ Client Fila de entrada

Retorno de mensagem
Fila de saída

Figura 10 – Arquitetura de integração da aplicação desktop com o mainframe.

5.1.2 Arquitetura de comunicação da camada mainframe

Na plataforma mainframe foi criado duas estruturas para permitir o fluxo do arquivo xml de
uma nota fiscal eletrônica enviada a partir da aplicação desktop para o Web Service da
SEFAZ.

A primeira estrutura são duas filas de mensagens. Uma fila de entrada e uma fila de saída.
Estas filas de mensagens foram criadas utilizando o IBM Websphere MQ. As filas de
mensagens funcionam como um repositório de dados, pois possibilitam que outros
componentes de software envolvidos na arquitetura consumam estes dados deixados nestas
filas como, por exemplo, o IBM CICS Transaction Server 3.2.

A segunda estrutura criada é uma simples aplicação COBOL desenvolvida para consumir os
dados da fila de entrada do IBM Websphere MQ e enviar para a SEFAZ. A Figura 11
exemplifica a interação das duas estruturas criadas no mainframe.
 43

MAINFRAME

Websphere MQ
Fila de entrada

Fila de saída
Envio da NF-e

Retorno da NF-e

AMBIENTE SEFAZ

Web Service:
NfeRecepcao

CICS TS
Retorno da NF-e
nfeRecepcaoLote
Aplicação COBOL

Envio da NF-e

Figura 11 – Processo de envio da NF-e para o mainframe.

5.2 Projeto e implementação do protótipo

Nas próximas seções será apresentado o projeto de implementação do protótipo emissor de

nota fiscal eletrônica.

5.2.1 Aplicação desktop

A aplicação desktop apresenta os seguintes componentes: classes Java implementando a

interface gráfica baseada em Java Swing, classes Java de conexão às filas de mensagem
implementando as funcionalidades da API do IBM Websphere MQ Client e uma classe Java
implementando uma thread para envio e retorno da NF-e.
 44

A interface gráfica contém um campo para indicar o caminho de entrada do arquivo xml junto
com um botão pra selecionar e carregar a NF-e dentro do emissor. Há uma tabela na interface
que exibe as entradas de NF-e realizadas no emissor. A Figura 12 representa a seleção de uma
NF-e no emissor.

Figura 12 – Seleção de um arquivo XML da NF-e preenchida.

A classe ConexaoFilaMensagem.java, responsável pela conexão às filas de mensagem, foi

implementada utilizando a API do IBM Websphere MQ Client. Esta classe contém todos os
métodos para conexão, envio e recebimento das mensagens vindas do IBM Websphere MQ
no mainframe. A classe ConexaoFilaMensagem.java é apresentada na Figura 13.
 45

public class ConexaoFilaMensagem {

private String hostname = "172.24.200.66";
private String channel = "CLIENT.CONN.PFRANCA";
private String qManager = "WMQA";
private MQQueueManager qMgr;
private MQQueue filaEntrada;
private MQMessage msgSaida;
private MQMessage msgEntrada;

public ConexaoFilaMensagem(){
MQEnvironment.hostname = hostname;
MQEnvironment.channel = channel;
MQEnvironment.properties.put(MQC.TRANSPORT_PROPERTY,
QC.TRANSPORT_MQSERIES_CLIENT);
}
public void conectar(String queue) throws MQException {
//cria a conexão com a queue manager
qMgr = new MQQueueManager(qManager);
int openOptions = MQC.MQOO_INPUT_AS_Q_DEF |
MQC.MQOO_OUTPUT;
filaEntrada = qMgr.accessQueue(queue, openOptions);
}

Figura 13 – Código Fonte da implementação da classe ConexaoFilaMensagem.java.

A classe Consulta.java implementa uma thread. Seu objetivo é fazer a chamada dos métodos
de envio e recebimento de mensagens da classe ConexaoFilaMensagem.java. Esta thread é
disparada de cinco em cinco segundos. A classe Consulta.java é apresentada na Figura 14.
 46

public class Consulta extends Thread{

private TelaPrincipal tela;
public Consulta(TelaPrincipal tela){
super();
this.tela = tela;
}

@Override
public void run(){
while(true){
try {
tela.getConexaoMQ().enviarMensagem();
tela.getConexaoMQ().receberMensagem();

Thread.sleep(5000);
} catch (InterruptedException ex) {
System.out.println("Erro na Thread!");
ex.printStackTrace();
} catch (IOException e) {
e.printStackTrace();
} catch (MQException e) {
e.printStackTrace();
}
}
}
}

Figura 14 – Código Fonte da implementação da classe Consulta.java.

Na figura 15 são apresentadas as principais classes que compõem a aplicação desktop. A

partir desta figura é possível ter a visão geral do relacionamento entre as classes.
 47

Figura 15 – Diagramas de classe da aplicação desktop

 48

5.2.2 Aplicação mainframe

A aplicação no mainframe é dividida em dois componentes: as definições das filas de

mensagem no IBM Websphere MQ e o componente para requisitar o Web Service da SEFAZ
escrito em COBOL utilizando as chamadas da API do IBM CICS Transactional Server.

As filas de mensagem foram definidas através do terminal de administração do WMQ no

mainframe. Foram definidas duas filas, uma de entrada chamada ENTRADA.FILA.NFE e
outra de saída chamada SAIDA.FILA.NFE. Estas definições servem para alocar as
requisições das NF-es vindas da aplicação desktop e as respostas vindas do Web Service da
SEFAZ, respectivamente. A Figura 15 apresenta o terminal de administração do WMQ.

Figura 16 – Tela de administração do WMQ.

O NFERECEP.cbl é o componente escrito em COBOL. Seu código possui chamadas da API

do CICS para requisitar o Web Service da SEFAZ de nome nfeRecepcaoLote. O objetivo do
NFERECEP.cbl é consumir a fila de entrada das NF-es, enviá-las para a SEFAZ e escrever a
resposta do Web Service na fila de saída do WMQ. A Figura 16 apresenta parte do código do
componente NFERECEP.cbl.
 49

Figura 17 – Código Fonte do componente NFERECEP.cbl

 50

6 CONCLUSÕES

Neste capítulo são apresentadas as considerações finais deste trabalho. A seção 6.1
apresentará as contribuições, conclusões e as experiências obtidas. A seção 6.2 apresenta
sugestões para trabalhos futuros.

6.1 Contribuições e Conclusões

Este trabalho propôs uma alternativa de integração de uma aplicação desktop Java com uma
aplicação disponível no ambiente mainframe utilizando um conjunto ferramentas e soluções
da IBM. Foi utilizado como estudo de caso o projeto da nota fiscal eletrônica do governo do
estado de São Paulo.

O trabalho proporcionou as seguintes contribuições:

a) Uma arquitetura de integração entre uma aplicação desktop e a alta
plataforma;
b) Apresentar algumas ferramentas e tecnologias do ambiente mainframe;
c) Uma proposta de arquitetura de integração entre a baixa e alta
plataforma para o projeto da nota fiscal eletrônica.

A partir destas contribuições, pode se concluir que:

a) A partir de estudos e análises dos softwares existentes no mercado foi
possível criar uma estrutura de comunicação entre aplicações em plataformas
distintas.
b) A utilização do mainframe oferece robustez ao sistema visto que as
soluções de nota fiscal eletrônica existente no mercado não possuem
implementação de componentes em mainframe.
 51

6.2 Trabalhos Futuros

Para trabalhos futuros sugere-se:

a) Complementação do protótipo com o desenvolvimento de outras
funcionalidades do Web Service da SEFAZ; e
b) Persistência de dados em banco de dados no mainframe.
 52

REFERÊNCIAS BIBLIOGRÁFICAS

BALBINO, Souza Junior; ALANIS, E. Objetos Distribuídos. Disponível em:

http://www.inf.unisinos.br/~barbosa/paradigmas/consipa2/artigos/a2.pdf. Acesso em 6 de abr. 2010.

BROWN, Gary DeWard; COBOL: The failure that wasn´t. Disponível em: http://
COBOLReport.com. Acesso em 16 de junho de 2010.

CERAMI, Ethan. Web Services Essentials, Editora: O`Reilly, 2002, 9 pg, 3pg, ISBN:
0596002246.

CSIS, Departament of Conputer Science and Information Systems. Disponível em:

http://www.csis.ul.ie/COBOL/Course/COBOLIntro.htm. Acesso em 16 de junho de 2010.

EDWARDS, J. 3-Tier Client/ Server at work, Editora: John Wiley, 1997, 147 pg, ISBN:
0471184438.

ENATE, Legislação da Nota Fiscal Eletrônica. Disponível em:

http://portalnfe.fazenda.mg.gov.br/downloads/legislacao_protocolo_enat_03_2005.pdf.
Acessado em 28 de março de 2011.

FAZENDA, Portal da Nota Fiscal Eletrônica, Fazenda. Disponível em:

http://portalnfe.fazenda.mg.gov.br/legislacao.html. Acessado em 28 de março de 2011.

IBM, CICS Transaction Server for Z/OS V3.2. Disponível em: http://www-

01.ibm.com/software/htp/cics/tserver/v32/features.html?S_CMP=rnav. Acesso em 29 de nov. 2010.

ITI, Definições da ICP-Brasil, Disponível em:

http://www.iti.gov.br/twiki/bin/view/Certificacao/CertificadoConceitos. Acessado em 23 de
julho de 2010.

MARINHO, B. L.; SORDI, J. O.; NAGY M. Benefícios da arquitetura de software orientada

a serviços para as empresas: Análise da experiência do ABN AMRO Brasil. Revista de
Gestão da Tecnologia e Sistemas de Informação. v. 3, n. 1, p. 19-34, 2006.
 53

MCCOY, D. W.; NATIS, Y. V. Service-Oriented Architecture: Mainstream Straight Ahead.

Gartner Research. 2003.

MOREIRA, Rogério de M. Fialho, A Implantação dos Juizados Virtuais na 5ª Região, Revista

ESMAFE – 5ª. n. 7, p. 52-54, 2004.

OASIS, Organization for the Advancement of Structured Information Standards. Disponível

em: http://www.oasis-open.org/org. Acesso em 15 de julho de 2011.

OMG, Object Management Group. Disponível em:

http://www.omg.org/gettingstarted/gettingstartedindex.htm . Acesso em 18 de novembro de
2010.

RATIONAL, IBM. Disponível em:

http://www-01.ibm.com/software/rational/products/developer/systemz/java/features/?S_CMP=wspace . Acesso
em 15 de dezembro de 2010.

RAYNS, C.; CAREY, D.; GARDNER, A.; NOTT, J.; SIMCOCK, A. Developing web
services using CICS, WMQ, and WMB, Editora: Redbooks, 2007, 8 pg, ISBN: 0738489239

RECEITA, Manual de Integração da Receita Federal - Contribuinte Padrão Técnico de

Comunicação, versão 4.01, 10pg, 67pg. Disponível em:
http://www.nfe.fazenda.gov.br/PORTAL/integracao.aspx. Acessado em 27 abril de
Novembro de 2011.

RONAYNE, M. L.; TOWNSEND, E. S. A Case Study: Distributed Object Technology at

Wells Fargo Bank. A Cushing group white paper, 1996.

SEFAZ, Orientação de Utilização do Sefaz Virtual, Ambiente Nacional para empresas, versão
1.0, 2pg. Disponível em: http://www.aprobatoneto.com.br/downloads/ManualSEFAZ.pdf.
Acessado em 26 de abril 2011.

SOMMERVILLE, I. Software Engineering 8th Edition, Editora: Addison Wesley, 2006 285
pg, ISBN: 0321313798.
 54

SUN, J2EE. Disponível em: http://java.sun.com/javaee/reference/glossary/index.jsp. Acesso em 23 de

julho de 2010.

THECHTERMS, Disponível em: http://www.techterms.com/definition/mainframe. Acessado

em 18 de julho de 2010.

THACKER, C. P. et al. Alto: A personal computer. Computer Structures: Principles and

Examples, New York, v. 2, p. 549-572, 1979.

VERONESE, A. Segredo e democracia: certificação digital e software livre. Revista

Informática Pública. Belo Horizonte. Ano 2008. n. 02.

WATTERSON, Karen. DB2 Does Data. Disponível em:

http://www.windowsitpro.com/article/product-review/db2-does-data/2. Acessado em 15 de
julho de 2010.

WMQC, IBM WebSphere MQ V7.0.0 information center. Disponível em:

http://publib.boulder.ibm.com/infocenter/wmqv7/v7r0m0/index.jsp. Acessado em Novembro de 2010.

W3C, SOAP Version 1.2. Disponível em: http://www.w3.org/TR/2007/REC-soap12-part0-20070427/.

Acesso em 20 de abr. 2010.

W3C, XML. Disponível em: http://www.w3.org/standards/xml/core. Acesso em 24 de julho de

2010.