Arquitecturas Tecnológica - fenix.tecnico.ulisboa.pt · Pedro Sousa ATSI 2005 Arquitectura...
Transcript of Arquitecturas Tecnológica - fenix.tecnico.ulisboa.pt · Pedro Sousa ATSI 2005 Arquitectura...
Pedro SousaATSI 2005
Arquitecturas Tecnológica
Pedro SousaATSI 2005
Arquitectura Tecnológica
O que é:• É a escolha dos tipos de tecnologia que devem ser
utilizados para dar suporte a cada um dos sistemas e aplicações definidos na Arquitectura de Aplicações, e aos Dados corporativos.
Tem como objectivo:• Perspectivar a tecnologia de forma independente dos
componentes funcionais e dos dados corporativos.
Pedro SousaATSI 2005
Exemplos de Tecnologias (1/2)
– Arquitectura das Aplicações (C/S, N-camadas, etc)
– Linguagens e ambientes de desenvolvimento
– Tecnologias de desenvolvimento (webservices, XML, etc etc etc)
– Modelos de Maturidade no Processo de Desenvolvimento de Software
– Sistemas de Gestão Documental
– Sistemas de BPMS
– Ambiente de Produção de Relatórios
– Ambiente de Exploração de Dados
– Segurança (Processos, Informação, Aplicação, Redes)
– Sistemas de Canalização de dados
– Sistemas de Midleware– Tecnologias de Repositório
de Dados (ficheiros/BD relacional, outra) etc.
Pedro SousaATSI 2005
Exemplos de Tecnologias (2/2)
– Ambientes de Desenvolvimento, Testes, Staging, Pré-produção e Produção
– Disaster Recovery– Backups– Single sign-on– Produtos específicos de um fabricante específico:
ERP SAP, ERP MS-NAVISION, etc, etc
Pedro SousaATSI 2005
• Como identificamos as Tecnologias ?• A que nível de detalhe devemos chegar ?
– Compilação das Tecnologias Possíveis– Alinhamento com as Regras da Organização– Selecção de alternativas limitadas para as várias
tecnologias
Identificação das Tecnologias
Pedro SousaATSI 2005
Identificação das TecnologiasExemplo
Tecnologia e SistemasCorrentes
Tendênciasde Mercado
Best practices deEngenhariade software
Recenseamentode
Tecnologias
Arquitecturade aplicações
“Universo” deTecnologias
Princípios de desenhode sistemas
e tecnologias de informaçãoRegras da Organização
Arquitecturade aplicações
•Adaptação à organização•Mapeamento para
Arquitectura de Aplicações•Elaboração das recomendações
Pedro SousaATSI 2005
Segu
ranç
a
Infra-estruturade Rede
Servidores e Estações de Trabalho
SGBD
SIG
Middleware
SAD Simuladores
DesenvolvimentoAplicacional
Helpdesk
Identificação das TecnologiasExemplo
O que recomendar em cada caso implica anos de experiência e está fora do âmbito da disciplina !!!
Pedro SousaATSI 2005
Ambientes de Desenvolvimento
• Caracterização do Ambientes de – Desenvolvimento– Teste– Pré-produção– Produção
• Relativamente ao – Dimensionamento – Nível de Disponíbilidade– Nível de Escalabilidade– Nível de Licenciamento
Pedro SousaATSI 2005
Caracterização do Ambientes de Desenvolvimento
• Relativamente a ferramentas de:– Desenvolvimento– Gestão de configurações – Gestão de Projectos– Teste e Gestão da Qualidade– Produtividade Pessoal– Trabalho cooperativo– Comunicação pessoal (email, news, etc)– backups
Pedro SousaATSI 2005
Caracterização do Ambientes de Produção
• Relativamente a ferramentas de:– Help Desk– Gestão de Configuração– Disaster recovery– backups– Monitorização e Gestão de Desempenho– Gestão de Licenças– Administração de utilizadores– Gestão da Capacidade
Pedro SousaATSI 2005
Questões • Quando é que as tecnologias são identificadas ?• Como é que as tecnologias se relacionam com a
Arquitectura de Aplicações ?
• Enumere algumas heurísticas de alinhamento tecnologia com aplicações?
• Como é que se representam as tecnologias nesta matriz ?
• O que podemos dizer sobre o que é um SI vs Aplicação vs tecnologia (ex um servidor de middleware) ?
• Como se valida cada um dos alinhamentos?
• E o alinhamento com a Tecnologia ?
Pedro SousaATSI 2005
Modelos e Representação
Arquitectura Aplicacionale
Arquitectura Tecnológica
Pedro SousaATSI 2005
Representações
• O que representar e como representar…– Aplicações,– Componentes (módulos) aplicacionais– Produtos específicos– Serviços– Interfaces– Dispositivos– Canal de comunicação– Redes– Infraestrutura SW (BD, SO, middleware, etc etc etc)
Pedro SousaATSI 2005
IS Block is defined asthe collection of
mechanisms andoperations organized in
order to manipulateorganization data
IT Block is the infrastructure, application platform andtechnological/software
component that realizes (orimplement) an (or several) IS
Block(s)
CEO Metamodel Profile
Pedro SousaATSI 2005
CEO Metamodel Profile
IS Business Blockpresents a “vertical”
rangeof operations
IS General Blocksupports common
operations in several business activities
areas – like spreadsheet,
email, calendar, scheduling or workflow
applications
Pedro SousaATSI 2005
CEO Metamodel Profile
Pedro SousaATSI 2005
CEO Metamodel Profile
Pedro SousaATSI 2005
CEO Metamodel vs. UML 2.0
Component
Node
Interface
Pedro SousaATSI 2005
A Norma IEEE 1471-2000
Pedro SousaATSI 2005
ARCHIMATE ViewPoints
Alguns viewpoints relevantes na Arq Aplicação e Tecnológica:• Application Structure• Infrastructure• Application Cooperation• Application usage• Infrastructure usage• Implementation & Deployment Viewpoint
Projecto www.archimate.com
Pedro SousaATSI 2005
Application Structure viewpoint
Pedro SousaATSI 2005
Application Structure
Pedro SousaATSI 2005
Infrastructure Viewpoint
Pedro SousaATSI 2005
Infrastructure Viewpoint
Pedro SousaATSI 2005
Application Cooperation Viewpoint
Pedro SousaATSI 2005
ApplicationCooperationViewpoint
Pedro SousaATSI 2005
Application Usage Viewpoint
Pedro SousaATSI 2005
Application Usage Viewpoint
Pedro SousaATSI 2005
Infrastructure Usage Viewpoint
Pedro SousaATSI 2005
Infrastructure Usage Viewpoint
Pedro SousaATSI 2005
Implementation & Deployment Viewpoint
Pedro SousaATSI 2005
Implementation & Deployment Viewpoint
Pedro SousaATSI 2005
Pedro SousaATSI 2005
Padrões Arquitecturais
Pedro SousaATSI 2005
Padrões Arquitecturais
• Tópicos– Integração– Tipos de Aplicações– Serviços– Camadas– Redes
Pedro SousaATSI 2005
Aspectos Arquitecturais da Integração de Dados
• Information Bus– As Aplicações acedem on-line aos dados das outras – Os processos são ligados por MSQ
Acesso à informação “on-line”Aspectos importantes
Pedro SousaATSI 2005
• Common Data Interface– Os Dados são Publicados num Base de Dados– Os processos são ligados por MSQ
1. Independência Computacional
2. Segurança3. Independência entre os
produtores e consumidores da Informação
Aspectos importantes
Aspectos Arquitecturais da Integração de Dados
Pedro SousaATSI 2005
Alta afinidade entre as entidades: a maioria das
entidades criadas por uma aplicação são usadas pelas
outras aplicações
Baixa afinidade entre as entidades: a maioria das
entidades criadas por uma aplicação não são usadas pelas outras aplicações
Padrões Arquitecturais por tipos de Aplicações
CommonData
Interface
R 4App - 4
R 5App - 5
R 6App - 6
Repositório Integrado
App - 1
App - 2
App - 3
Data Warehouse
App - 7
App - 8
App - 9
Suites Integradas (ERP, CRM, etc)
EIS, DSS, etc
Outros SistemasOperacionais
Forte indices de leitura de outras entidades e as
eventuais entidades criadas não são lidas por nenhuma
outra aplicação
Pedro SousaATSI 2005
39
Matriz CRUD (1)
Entidades Clie
nte
Forn
eced
or
Col
abor
ador
Enco
men
da
Dev
oluç
ão
Ord
em d
e Tr
abal
ho
Prod
uto
Arm
azém
Loja
Vend
a
Rec
urso
Veic
ulo
Rot
a
Banc
o
Con
ta P
OC
Con
corr
ente
Plan
o P
rodu
ção
Gerir Encomendas RU R R CRUD R R R RGerir Comercial CRUD CRUD R R R R CRUD R R R R CRUDGerir Armazéns R R RU CRUD CRUD RU RU RUGerir Comunicação R R R R R R R R R R RGerir Distribuição R R CRUD CRUD R R R RU RGerir Vendas / Lojas R R CRUD CRUD RU RU CRUD RUGerir Importações R R RU CRUD R R RGerir Logística Inversa R R R R RU R R R R R RGerir Produção R CRUD CRUD RU R R R CRUDGerir RH CRUD RGerir Contencioso R R R RGerir Infra-estruturas R CRUD CRUD CRUD CRUDGerir IT / IS R R R CRUDGerir Financeira R R R R R R R R R R R CRUD CRUD
Pedro SousaATSI 2005
CommonData
Interface
R 4App - 4
R 5App - 5
R 6App - 6
Repositório Integrado
(ex ERP)
App - 1
App - 2
App - 3
Data Warehouse
App - 7
App - 8
App - 9
Podem existir váriasSuites Integradas (ERP, CRM, etc) EIS, DSS, etc
Outros SistemasOperacionais
Repositório Integrado(ex CRM)
App - 10
App - 11
App - 12
Padrões Arquitecturais por tipos de Aplicações
Pedro SousaATSI 2005
Empresa
“Participadas”
“Holding”
ClientesFornecedores
• A Arquitectura de Integração deverá exibir de forma clara:– As Interfaces pré-definidas, tanto do ponto
de vista funcional como tecnológico.– A Consolidação na “holding”.– A visão de um DW corporativa– As Integrações com os sistemas outras
empresas, como por exemplo para as integrações B2B
Padrões Arquitecturais por tipos de Aplicações
Pedro SousaATSI 2005
Repositório
IntegradoCommon
Data Interface
R 4App - 4
R 5App - 5
R 6App - 6
App - 1
App - 2
App - 3
Data Warehous
e
App - 7
App - 8
App - 9
Repositório Integrado
CommonData
Interface
R 4App - 4
R 5App - 5
R 6App - 6
App - 1
App - 2
App - 3
Data Warehouse
App - 7
App - 8
App - 9
Repositório Integrado
CommonData
Interface
R 4App - 4
R 5App - 5
R 6App - 6
App - 1
App - 2
App - 3
Data Warehouse
App - 7
App - 8
App - 9
CorporateData
Warehouse
Empresa mãe
Empresaparticipada
ClientesFornecedores Clientes
Fornecedores
Clientes/Fornecedores
Empresaparticipada
Padrões Arquitecturais por tipos de Aplicações
Pedro SousaATSI 2005
Relação com os Frameworks
Pedro SousaATSI 2005
Questões
• Como é que estas 4 Arquitecturas ligam com os Framework de Arquitecturas Empresariais ?
• Nos framework de Zackman, onde reside a informação que relaciona várias células
• O papel da Arquitectura de Informação
Pedro SousaATSI 2005
Versão Arquitectura Empresarial
Pedro SousaATSI 2005
Arquitectura de um Sistema ou Aplicação
Pedro SousaATSI 2005
Arquitectura de Aplicações
• Todas as aplicações têm 3 componentes estruturais:
• As diferenças começam com a introdução de troços de rede entre as componentes!
Apresentação Lógica Dados
Pedro SousaATSI 2005
Arquitectura de Aplicações
• Arquitecturas Cliente - Servidor
Apresentação
Lógica
Dados
Apresentação
Rede
Servidor
Cliente Apresentação
Lógica
Dados
Apresentação
Lógica
Dados
Lógica
Apresentação
Dados
Lógica
Apresentação
Dados
Lógica
Dados
ApresentaçãoDistribuída
ApresentaçãoRemota
LógicaDistribuída
Dados Remotos
Base de DadosDistribuídos
“Fat Server” “Fat Client”
Pedro SousaATSI 2005
Arquitectura de Aplicações
• Arquitecturas de 1,2,3 e N Camadas
• Pontos críticos– Administração– Segurança– Encapsulação de Dados– Desempenho– Disponibilidade– Reutilização– Facilidade de Desenvolvimento– Integração com Sistemas Legados– Escalabilidade e Flexibilidade no hardware
Apresentação Lógica Dados
Pedro SousaATSI 2005
Arquitectura de Aplicações
• A Flexibilidade das Arquitecturas de 3 Camadas
N servidores aplicacionais(HW e/ou SW)
N servidores deBase de Dados
(HW e SW)
Pedro SousaATSI 2005
Arquitectura de Aplicações
• A Arquitectura Típica de Hardware explicita as 3 zonas de segurança distinta.
• As firewalls permitem limitar os acessos (quem e o quê) entre os troços de rede
• Não existe necessariamente uma correspondência com as 3 camadas das aplicações!
Firewall #1
Rede LocalClientes
Firewall #2
Servidores Aplicacionais
Servidores de Base de Dados
Pedro SousaATSI 2005
Arquitectura de Aplicações
• A Arquitectura Típica de Hardware para a Web
• Os clientes são constituídos por um Browser mais o Servidor Web
• A mesma Firewall pode isolar vários ambientes:
Firewall #1
Firewall #2
Servidores Aplicacionais
Servidores de Base de Dados
InternetBrowsers
Firewall #0
Servidores Web
Clientes
Internet
Firewall #0Servidores Web
ServidoresAplicacionais
Pedro SousaATSI 2005
Catalogue & SearchCommerce Center
Site Web Server
Production Environment
Pre-Production Environment
Application ServersWeb Servers
Developer Environment
Data Center Environment
DBMS
Firewall #3
Community
DBMS
DBMS
Auction
Reliable Hosts
Scalable Hosts
DMZ Environment
Firewall #1
Content Management Center
Tax
Payment Gateway
Firewall #2
Other Networks
Unix/NT
MarketplaceWeb Servers
Internet
Exemplo -Arquitectura da Infra-estrutura de redes
Pedro SousaATSI 2005
Arquitecturas de Alta Disponibilidade
• Uso de servidores de backup– Detecção da falha– Actualização dos Backup –
Aplicação dos Logs– Activação da aplicação– Re-processamento das mensagens
perdidas
• Duplicação PassivaUm servidor de reserva!
– “Transparente” para o utilizador– Actualização dos Backup –
Aplicação dos Logs– Activação da aplicação– Re-processamento das mensagens
perdidas
Servidores Aplicacionais
Servidores deBase de Dados
Servidores de backup
Cluster de Servidores
Pedro SousaATSI 2005
Arquitecturas de Alta Disponibilidade
• Duplicação ActivaUm servidor de reserva, mas a
trabalhar !
– “Transparente” para o utilizador– Ideal para servidores sem
estado!– Grandes percas no desempenho
com:• a actualização de dados • a distância entre os
servidores e discos
ServidoresAplicacionais
Stateless
Servidores deBase de Dados
Cluster de Servidores
ServidoresWeb
Stateless
Load Balancing (Hw ou SW)
Pedro SousaATSI 2005
Arquitecturas Escaláveis
Como desempenho do HW actual, porquê que ainda temos problemas com o desempenho dos Processadores?
ü Decomposição do tempo gasto numa transacção óptima:ü 10% – CPUü 30% – Rede ü 30% – Base de Dadosü 30% – Idle (caso
contrário as queuesentram em “trash”)
ü Com transacções distribuídas, o cenário ébastante pior
RedeProcessador & Memória IO
Base de Dados
Log
Tipicamente, 5 a 20 IOspor transacção
Pedro SousaATSI 2005
Arquitecturas Escaláveis
• Tópicos relevantes:– Que limites para o paralelismo– Processamento Transaccional Online– Processamento Batch– Distribuição como Alternativa ?– Distribuição de Carga– Sistemas Operacionais e Analíticos – Backups e recovery
ServidoresAplicacionaisStateless &
Load balaced
Servidores deBase de Dados
Clustered
Cluster de Servidores
ServidoresWeb
Stateless &Load balaced
Pedro SousaATSI 2005
Integração de AplicaçõesEnterprise Application Integration
• Existem 4 tipos de integração de Aplicações:
– Ao nível da Apresentação
– Ao nível do método ou processo
de Negócio (com ou sem APIs
aplicacionais)
– Ao nível dos Dados
Apresentação
Lógica
Dados
Apresentação
Lógica
Dados