Integração de Sistemas

ARQDESISMULTI - Prof. Sergio Bonato - USJT - 2019

 Integração
• Transferência de Arquivos

• RPC

• CORBA

• RMI

• JEE

• SOAP

• REST
Webservices SOAP
Restful Webservices XML e JSON
XML x JSON
SOA - Arquitetura Orientada a
Serviços
A “evolução” de uma arquitetura...
Criando a necessidade de um novo paradigma de
arquitetura

Barramento de Serviços
 Exemplo de aplicação EXEMPLO
Presentation

Layer
Laboratórios Institutos Planos
Clientes Médicos Empresas
Parceiros de Pesquisa de Saúde
Processo de Agendamento
Laboratório
Telefone Internet Unidades
Parceiro
Identificar cliente Localizar
Início através do RG ou cadastro do
Business 
 Análises Centro de Laboratório Pesquisas Promoção Hospital CPF cliente
Check-Up
Process
 Clínicas Diagnósticos de Referência Clínicas de Saúde Dia
Layer
Elaboração do Publicação do
Pré-Atendimento Atendimento Procedimento Solicitar convênio ,
Relatório Relatório Localizar Cadastro
empresa e plano SIM
convênios localizado?
do cliente

NÃO

Business
 Consultar Convênio Cadastrar

Consultar Enviar Instruções
Consultar Clientes Profissional de Consultar Fichas localizado ? novo cliente
Service
 Saúde
Convênios Personalizadas
Layer Cadastrar
Consultar Escala Consultar SIM
Cadastrar Clientes Profissional de Abrir Ficha NÃO
Médica Resultados
Saúde
Atualizar Informar sobre a Confirmar
Consultar Grade de não cobertura e Unidade mais Solicitar leitura do
Atualizar Clientes Profissional de Consultar Laudos Imprimir Etiquetas
Serviços oferecer serviço próxima ou pedido médico
Saúde
particular preferencial
Consultar Consultar Confirmar
Consultar Produtos ...
Medicamentos Bloqueios Agendamento
NÃO

Horários Consultar
Consultar
aceitos pelo Horários
Profissional de Produtos
cliente? Disponíveis
Clientes Convênios Grade de Serviços Fichas Resultados
Saúde
SIM
Produtos Medicamentos Escala Médica Bloqueios Agendamento Laudos

Enviar
Confirmar
Instruções Fim
Agendamento
Personalizadas
Application

Layer
SSAC SAD Sistema Técnico Laudário ...

9
Computação Orientada a Serviços
Termo abrangente que representa uma nova geração de
plataforma de computação distribuída.

É um paradigma que inclui princípios de projeto, padrões

de projeto, um modelo de arquitetura próprio e conceitos,
tecnologias e frameworks relacionados.
Está construído sobre as plataformas de computação
distribuída do passado e adiciona a elas novas camadas
de desenho, considerações de governança e um vasto
conjunto de implementações tecnológicas, vários deles
baseados em web services.
 Orientação a Serviços
Orientação a serviços é um paradigma de design
projetado para a criação de unidades lógicas de
solução que são individualmente formatadas de modo
que sejam coletivamente e repetidamente utilizadas no
suporte da realização de objetivos estratégicos
específicos e benefícios associados com SOA e
computação orientada a serviços.
Lógica de solução são conjuntos de funcionalidades,
técnicas ou de negócio. Se forem construídas com
orientação a serviços são chamadas de serviços.
Ex: Serviço de ordem de compra com os métodos
EnviarOrdem, VerificarStatusDaOrdem, AlterarOrdem e
Cancelar Ordem.
 Serviço
É um container de funcionalidades com um
propósito comum.

Um serviço pode ser consumido por uma

aplicação desktop, aplicação servidor ou por
outro serviço. Neste caso temos um serviço
provedor e um outro consumidor

Vários serviços podem ser agregados em uma

composição de serviços para se implementar
funcionalidades de negócio.
Arquitetura Orientada a Serviços

SOA é um conjunto de práticas, processos,

tecnologias e, principalmente, pessoas, cujo
objetivo é a criação e a integração de
sistemas heterogêneos e distribuídos
baseada em unidades lógicas de solução
chamadas de serviços.
Evolução para Orientação a Serviços
• O grande objetivo de TI é construir sistemas interoperáveis, plug & play, que
enderecem processos de negócio.
• Cada nova onda de tecnologia tem reduzido o nível de acoplamento para que isso
seja possível.
• SOA reconhece que os sistemas são heterogêneos e trabalha a favor disso.
acoplamento
1970 1980 1990 2000
Mainframe Cliente Servidor Componentes SOA
Distribuídos
# de camadas 1 2 n n
Tecnologia Linguagem de Padrões de Programação Padrões (XML,
Programação acesso a dados Distribuída SOAP, etc)
(COBOL) (ODBC) (CORBA, RMI,
COM, EJB, etc)
Nível de Intra-aplicação Entre clientes Entre aplicações Entre aplicações
Interoperabilidade Intra-empresa Entre empresas

Elementos Mesma máquina, Mesma tecnologia Mesmos padrões

comuns mesma de comunicação e
tecnologia, mensageria
mesmo programa
interoperabilidade
Falta de reutilização, dificuldade de integração em
busca de alinhamento com o negócio.
• As empresas ainda optam por customizar seus
sistemas corporativos, muitas vezes para
atender a requisitos fora do seu escopo original.
Sistema Sistema
Externo 2 Externo 1

Código
Customizado

CRM
Reutilização, integração e alinhamento com o
negócio.
• Em uma arquitetura orientada a serviços, as
customizações são novos serviços,
reaproveitáveis para vários canais.
BPM Sistema

Barramento de Serviços
Externo 1

Código
Customizado
Sistema
Externo 2

CRM
 Arquitetura de Referência SOA

Capacidades de Capacidades SOA Runtime Capacidades de
Gestão do Ciclo 
 Gestão e Controle
de Vida SOA Canais SOA
Desenvolvimento Portal Mail iPad/iPhone SMS Impresso Controle
Operacional
Desenho
Apresentação
Logging e
Desenvolvimento Aplicação / Portal Auditoria

Monitoramento
Teste Processo Processo Processo Processo
BPM
Implantação Performance

Modelos e
ESB UDDI XSD Controle SLA
Padrões

Repositório de Serviços Controle de

Serviços Políticas
Identificação Orquestração Gestão Segurança
(UDDI)
Repositório de Repositório de
meta dados Barramento Técnico Políticas
Gerenciamento de Controle de
ciclo de vida Sistemas VUC DBM ECM Políticas
 Modelo de Dados Canônico
• Sistemas que trocam dados entre si necessitam de uma semântica
comum para se entenderem. Compartilhar uma semântica de
dados é a chave do sucesso para iniciativas SOA, e inclusive para
qualquer sistema baseado em mensagens. É o nível mais alto de
desacoplamento que sistemas podem ter, pois cria uma camada
lógica para interagirem. Quando um conjunto de programas se
comunica, mas não possuem uma semântica compartilhada,
qualquer outro nível de desacoplamento se torna pouco útil.

• Um modelo de dados canônico não é um framework de

persistência, uma ferramenta, ou um sistema de armazenamento.
Ele é um modelo lógico de dados que deve ser utilizado para as
comunicações e mensagens entre sistemas. Funciona como uma
língua franca entre as aplicações.

• Ao utilizar um modelo canônico o número de transformações que

deveria existir entre sistemas é reduzido radicalmente. Cada
sistema, só precisa se preocupar em transformar suas mensagens
para um único formato, e então trocar mensagens com outros
sistemas que estejam de acordo com esse formato. Sem um
modelo canônico a quantidade de transformações cresce se torna
extremamente complexa de gerenciar.
Governança
 Framework de Governança
• O objetivo da Governança em SOA é assegurar e propagar na corporação
uma migração em direção à uma arquitetura flexível e inovadora baseada em
princípios de orientação à serviços: interoperabilidade, reutilização,
desacoplamento, modularidade, serviços padrões, foco em processo, entre
outros... Centro de Competência
SOA é a nova estrutura
Estrutura Organizacional
com um duplo papel de
Program Project/ Infrastructure centro de governança,
Governança SOA Corporate/ Business Business
IT Governance Management Project Team IT
Team bem como suporte para
envolve Teams Teams
os Arquitetos de Negócio
representantes de
diferentes
estruturas de TI e Governança dos Processos SOA
de Negócio
SOA Strategy & Planning

Service Business Policy Service

Lifecycle
Management Alignment Management Monitoring
Centro de
Processos de
Capability Development Competência
Governança são
SOA
suportados por
ferramentas Ferramentas de Governança Centrais
específicas e
Guida
 e
Guidelines Policy
centralizadas Service Linee Process Monitoring
e Standard Enforcement
Repository Standard Library Tool
Tool
 Microserviços
• Serviços totalmente independentes de
dados próprios
• Usa conceitos de SOA
• Uso de componentes
• Uso de message broker com bem
menos funcionalidades do que um
enterprise service bus
• Evitar ao máximo dependências e
orquestração
• Bom para rodar em plataformas na
nuvem