arquitetura de sistemas e padroes de projeto - aula 01 - parte 02
DESCRIPTION
Aula 01 da disciplina Análise Orientada a Objetos e Projeto Arquitetural no UNIPAM.TRANSCRIPT
Graduado em Sistemas de Informao (UNIPAM) Mestrado em Cincias da Computao (UFU) Analista de Sistemas Senior Mercado Financeiro Professor FPU UNIPAM Java .NET Scala C/C++
Augusto A. B. Branquinho. 05/05/2012
SUMRIO1. Arquitetura de Sistemas1.1. Orientado a Objetos 1.2. Cliente / Servidor 1.3. N-Tier / 3-Tier 1.4. Componentes 1.5. Domain Driven Design 1.6. Barramento de mensagens 1.7. Orientado a servios (SOA)
Referncias.com
Estilos
de arquitetura Communication Deployment Domain StructureArchitecture styles Service-Oriented Architecture (SOA), Message Bus Client/Server, N-Tier, 3-Tier Domain Driven Design Component-Based, Object-Oriented, Layered Architecture
Category Communication Deployment Domain Structure
.com
Arquitetura
de Sistemas Um sistema envolve vrios estilos de arquitetura No existe a melhor arquitetura Existe a melhor soluo de arquitetura para um cenrio bem definido
.com
SUMRIO1. Arquitetura de Sistemas1.1. Orientado a Objetos 1.2. Cliente / Servidor 1.3. N-Tier / 3-Tier 1.4. Componentes 1.5. Domain Driven Design 1.6. Barramento de mensagens 1.7. Orientado a servios (SOA)
Referncias.com
Abstrao Composio Herana Encapsulamento Polimorfismo Desacoplamento
.com
Benefcios
Compreensvel Reutilizvel Testvel Extensvel Alta
Coeso
.com
SUMRIO1. Arquitetura de Sistemas1.1. Orientado a Objetos 1.2. Cliente / Servidor 1.3. N-Tier / 3-Tier 1.4. Componentes 1.5. Domain Driven Design 1.6. Barramento de mensagens 1.7. Orientado a servios (SOA)
Referncias.com
Uma
das arquiteturas mais citadas Historicamente a mais importante Cliente se comunica individualmente com o servidor Separado
em diferentes computadores Compartilham recurso Um
servidor pode ser o cliente de outro servidor.com
Exemplo Web
muito comum
server
Difcil
escalabilidadecontexto.com
Compartilhar
Peer-to-peer
Cliente/Servidor
Peer-to-peer Mesma
aplicao compartilhando objetos em vrias instncias.com
Comunicao Socket
UDP TCP
RPC
(Remote Process Call) RMI (Remote Method Invoke) SOAP (Simple Object Access Protocol) Distributed Exerccios:
System [1]1.3, 1.5.com
.com
Projeto
de exemplo
Servidor
UDP Cliente UDP Simples mapa de um jogo Movimentos randmicos gerados pelo servidor Projetos Wpattern-client Wpattern-client-server-utils Wpattern-server.com
.com
.com
Projeto
de exemplo
SVN: http://wpattern.codeplex.com/ sample projects java wpattern-udpclient-server Blog: http://wpattern.com
SUMRIO1. Arquitetura de Sistemas1.1. Orientado a Objetos 1.2. Cliente / Servidor 1.3. N-Tier / 3-Tier 1.4. Componentes 1.5. Domain Driven Design 1.6. Barramento de mensagens 1.7. Orientado a servios (SOA)
Referncias.com
Separao
entre segmentos Cada segmento uma camada Cada camada tem uma responsabilidade Podem estar separados fisicamente Geralmente usam um padro para comunicao Melhorar o uso de recursos Algumas interaes podem ser assncronas.com
Manutenabilidade Mais
fcil de manter cada camada
Acoplamento Normalmente Baixa
o acoplamento alto
Escalabilidade Tolerncia Baixa
a falha
.com
Avaliar
se uma camada no consome recursos de outras camadas preciso avaliar o nvel de segurana de cada camada Dependncia lgica entre camadas importante avaliar quantas camadas so necessrias Para
sistemas mais simples temos apenas 3 camadas.com
3-Tier
(arquitetura em camadas mais comum) Presentation
Layer Business Layer Data Layer Sistemas
menores Sistemas intranet Adio do Service Layer.com
.com
.com
1.2. 3. 4. 5. 6.
7.8. 9.
Escolher sua estratgia de camadas Determinar o que cada camada requer Definir como distribuir as camadas Determinar se preciso unir camadas Determinar as regras de interao entre camadas Determinar os interesses dos mdulos Definir a interface entre as camadas Determinar a escolha da estratgia de deploy Escolher o protocolo de comunicao.com
Mais
detalhes da camada Presentation Layer
.com
Presentation
Layer
Componentes de interface do usurio Lgica dos componentes de interface Presentation
Layer (consideraes)
Escolher o tipo de aplicao (web, desktop, ...) Escolher o tipo de tecnologia da interface Usar os padres relevantes (MVC, MVVM, MVP, ...) Projetar com a separao de responsabilidades Considerar a usabilidade Projetar o Presentation Layer de acordo com as necessidades do usurio.com
Presentation
Layer (questes especficas)
Caching Communication
Composition Exception
Management Navigation User Experience User Interface Validation
Mais
detalhes da camada Business Layer
.com
Business
Layer
Componentes de negcio Entidades do negcio Fluxo de regras do negcio Business Layer (consideraes)
Decidir se preciso ser separado Identificar as responsabilidades e os consumidores No misturar diferentes tipos componentes Reduzir o nmero de acessos (caso seja remoto) Evitar a dependncia entre outras camadas
.com
Business
Layer (questes especficas)
Authentication Authorization Caching
Coupling
and Cohesion Exception Management Logging, Auditing, and Instrumentation Validation
.com
Mais
detalhes da camada Data Layer
.com
Data
Layer
Componentes de acesso a dados Agentes de servios Componentes utilitrios
Data
Layer (consideraes)
Escolher a forma de acesso a dados Usar abstrao para implementar o baixo acoplamento com a interface de dados Encapsular o acesso a dados Decidir como mapear as entidades.com
Data
Layer (consideraes)a consolidao de dados (DTOs)
Considerar
Decidir como gerenciar as conexes Decidir como gerenciar as excees Considerar riscos de segurana Reduzir os processos de busca de dados Avaliar objetivos de escalabilidade e performance
.com
Data
Layer (questes especficas)
Batching Binary
Large Objects (BLOBs) Connections Data Format Exception Management Object Relational Mapping
.com
Data
Layer (questes especficas)
Queries Stored
Procedures Stored Procedures vs. Dynamic SQL Transactions Validation XML
.com
.com
Service
Layer
Interface
dos servios Tipos de mensagens Implementao dos servios Pode ser realizado separadamente Service
Layer (consideraes)
Projetar
os servios baseados no escopo da aplicao Projetar os servios e contratos extensveis.com
Service
Layer (consideraes)
Projetar
os servios considerando que no conhecem os clientes A camada deve implementar apenas o contrato Separar as responsabilidades dos servios e de infraestrutura Usar um padro para compor as entidades Projetar considerando requisies invlidas.com
Service
Layer (consideraes)Layer (questes especficas)
Projetar
uma interface de contrato separada da implementao
Service
Authentication Authorization
Communication Exception
Management Messaging Channels.com
Service
Layer (questes especficas)
Message
Construction Message Endpoint Message Protection Message Routing Message Transformation Service Interface Validation
.com
Projeto
de exemplo
SVN:-FPU-
https://github.com/bbranquinho/Hibernate-Example-
Blog: http://wpattern.com Posts:
http://wpattern.com/blog/post/2011/09/09/Introducaoao-Hibernate-(Componentes)-Parte-01.aspx http://wpattern.com/blog/post/2011/09/11/Introducaoao-Hibernate-(Configuracao-do-Ambiente)-Parte-02.aspx http://wpattern.com/blog/post/2011/09/11/Introducaoao-Hibernate-(Explicacao-da-Arquitetura-eDesenvolvimento-do-Utils)-Parte-03.aspx.com
Projeto
de exemplo
Posts:
http://wpattern.com/blog/post/2011/09/11/Introducaoao-Hibernate-(Configuracao-do-Hibernate)-Parte-04.aspx http://wpattern.com/blog/post/2011/09/11/Introducaoao-Hibernate-(Criacao-Entidades-e-do-Banco-de-Dados)Parte-05.aspx http://wpattern.com/blog/post/2011/09/11/Introducaoao-Hibernate-(Criacao-dos-DAOs)-Parte-06.aspx http://wpattern.com/blog/post/2011/09/12/Introducaoao-Hibernate-(Criacao-dos-Servicos)-Parte-10.aspx http://wpattern.com/blog/post/2011/09/12/Introducaoao-Hibernate-(Testes-dos-Servicos)-Parte-12.aspx.com
Projeto
de exemplo
Posts:
http://wpattern.com/blog/post/2011/09/12/Introducaoao-Hibernate-(Integracao-da-Interface-com-os-Servicos)Partes-13-e-14.aspx http://wpattern.com/blog/post/2011/09/23/Introducaoao-Hibernate-(Consideracoes-Finais)-Parte-15.aspx
.com
.com
.com
.com
.com
SUMRIO1. Arquitetura de Sistemas1.1. Orientado a Objetos 1.2. Cliente / Servidor 1.3. N-Tier / 3-Tier 1.4. Componentes 1.5. Domain Driven Design 1.6. Barramento de mensagens 1.7. Orientado a servios (SOA)
Referncias.com
Modelar
a arquitetura por mdulos/
projetos Cada mdulo um componente Tratar individualmente cada parte do sistema Segregar responsabilidades Subsistemas trabalhando em conjunto para formar um sistema completo.com
Princpios nica
responsabilidade Open/Close Orientado a interfaces Inverso de dependncia Altamente coesos No pode duplicar implementaes No pode expor detalhes internos Entender como ser a comunicao entre componentes.com
Aplicar
os princpios chave da arquitetura baseada em componente Reutilizvel Substituvel Extensvel Encapsulado Independente
.com
Mercados
Plataforma 1
Plataforma 2
Plataforma 3
FIX 5.0
Market
Server
Broker
Risk
Manager
Order
Recovery Database
BD Cassandra
Admin
Account
Web
Configuration.com
Plataforma 1
Plataforma 2
Plataforma 3
.com
Mercados
Plataforma 1
Plataforma 2
Plataforma 3
.com
Mercados
Plataforma 1
Plataforma 2
Plataforma 3
Admin
Broker
.com
Mercados
Plataforma 1
Plataforma 2
Plataforma 3
FIX 5.0
Server
Admin
Broker
.com
Mercados
Plataforma 1
Plataforma 2
Plataforma 3
FIX 5.0
Market
Server
Admin
Broker
.com
Mercados
Plataforma 1
Plataforma 2
Plataforma 3
FIX 5.0
Market
Server
Broker
Manager
Admin
.com
Mercados
Plataforma 1
Plataforma 2
Plataforma 3
FIX 5.0
Market
Server
Broker
Risk
Manager
Admin
.com
Mercados
Plataforma 1
Plataforma 2
Plataforma 3
FIX 5.0
Market
Server
Broker
Risk
Manager
Order
Admin
.com
Mercados
Plataforma 1
Plataforma 2
Plataforma 3
FIX 5.0
Market
Server
Broker
Risk
Manager
Order
Recovery
Admin
.com
Mercados
Plataforma 1
Plataforma 2
Plataforma 3
FIX 5.0
Market
Server
Broker
Risk
Manager
Order
Recovery Database
Admin
.com
Mercados
Plataforma 1
Plataforma 2
Plataforma 3
FIX 5.0
Market
Server
Broker
Risk
Manager
Order
Recovery Database
BD Cassandra
Admin
.com
Mercados
Plataforma 1
Plataforma 2
Plataforma 3
FIX 5.0
Market
Server
Broker
Risk
Manager
Order
Recovery Database
BD Cassandra
Admin
Account
.com
Mercados
Plataforma 1
Plataforma 2
Plataforma 3
FIX 5.0
Market
Server
Broker
Risk
Manager
Order
Recovery Database
BD Cassandra
Admin
Account
Configuration.com
Mercados
Plataforma 1
Plataforma 2
Plataforma 3
FIX 5.0
Market
Server
Broker
Risk
Manager
Order
Recovery Database
BD Cassandra
Admin
Account
Web
Configuration.com
Comunicao
via interface Componente usa a interface Recebe a instncia de um objeto Realiza chamadas dos mtodos da interface Componente implementa a interface Implementa uma determinada regra
.com
Market
Server
Broker
Risk
Manager
Order
Recovery
Database
.com
Market
Server
Risk
Manager
Order
Recovery
Database
.com
Market
Order
Risk
Manager
Server
Recovery
Database
.com
Utils
Market
Order
Risk
Manager
Server
Recovery
Database
Factory.com
Utils
Dependncia
Market
Order
Risk
Manager
Server
Recovery
Database
Dependncia
Factory.com
Simplificamos
o desenvolvimento
Monoltico Distribudo Quando dividimos mdulos em mquinas podemos usar o padro de projeto Adapter Os mtodos das interfaces do tipo de chamada (Sncrona ou Assncrona) Sncrona Pode ter retorno de valores (objetos ou tipos primitivos) Assncrono Todo retorno deve ser void
.com
Utils
Dependncia
Market
Order
Risk
Manager
Server
Recovery
Database
DependnciaFactory 1 Factory 2
Dependncia
.com
Mercados
Plataforma 1
Plataforma 2
Plataforma 3
Market Order Risk
Market Adapter
Socket (TCP/IP)
Server Adapter
Server Manager Recovery Database
.com
Exemplo
de projeto Servidor baseado em componentes Possui servios RMI Cliente baseado em componentes Consome servios RMI Blog: http://wpattern.com
.com
.com
.com
.com
.com
.com
SUMRIO1. Arquitetura de Sistemas1.1. Orientado a Objetos 1.2. Cliente / Servidor 1.3. N-Tier / 3-Tier 1.4. Componentes 1.5. Domain Driven Design 1.6. Barramento de mensagens 1.7. Orientado a servios (SOA)
Referncias.com
Organizar
os detalhes do domnio do negcio a nvel de aplicao Aproximar as regras de negcio com a realidade do desenvolvimento Encapsular as regras de negcio Relaciona conceitos do domnio do negcio com artefatos de Software Regras Mdulos.com
Representao PowerPoint Diagramas
dos modelos
UML Rascunho em papel Diversos outros meios de representao Domain Criar
model
um modelo comum entre o negcio e os Stakeholders O time usa para se comunicar sobre os requisitos do sistema, entidade de dados e modelo de processos.com
Domain
Model
Modular Extensvel
Fcil
de manter Refletir o modelo de negcio Melhorar a reusabilidade e testabilidade do domnio de objetos de negcio No
usar DDD impacta em camadas infladas e um Domain Model anmico.com
.com
SUMRIO1. Arquitetura de Sistemas1.1. Orientado a Objetos 1.2. Cliente / Servidor 1.3. N-Tier / 3-Tier 1.4. Componentes 1.5. Domain Driven Design 1.6. Barramento de mensagens 1.7. Orientado a servios (SOA)
Referncias.com
Integrao
entre aplicaes Diferentes tecnologias Diferentes plataformas Comunicao baseada em mensagens Produo
e consumo de mensagens
Baixo
custo na adio e remoo de aplicaes
.com
Problemas
comuns entre comunicao de sistemas Dependncia
entre as aplicaes A aplicao de requisio precisa conhecer o receptor O receptor precisa conhecer a mensagem Em uma comunicao ponto a ponto temos (n * (n 1)) / 2 conexes Manuteno, custo e alteraes.com
N Computadores
N de Conexes
2 3 4 5 6 7 8 9 10
1 3 6 10 15 21 28 36 45
.com
Problemas Alterar
comuns entre comunicao de sistemasa interface de todas aplicaes no to simples Aplicaes proprietrias
.com
Soluo:
Barramento de Mensagens
Transporte de mensagens entre aplicaes 3 elementos Conjunto de mensagens permitidas Conjunto de mensagens comuns Infraestrutura para o barramento de mensagens Envia
mensagens apenas para o barramento Recebe mensagens apenas do barramento.com
O
cliente passa um listener para o barramento Normalmente diminui o fluxo de mensagens Normalmente no garante a ordem das mensagens Precisa ter um tratamento interno No barramento preciso de otimizao, roteamento e armazenamento.com
Aplicao 1
Aplicao 2
Aplicao 3
Aplicao 4 Aplicao 5
Aplicao 6
Aplicao 7
Message BUS (Barramento de Mensagens)
Aplicao 8
Aplicao 9
Aplicao 10
Aplicao 11
.com
Problema
para a adio de mais uma aplicao
.com
O
Barramento deve conhecer sintaticamente a mensagem O Barramento no precisa conhecer semanticamente a mensagem Baseado em Publish/Subscribe Plublish:
envio de mensagem para o barramento Subscribe: escuta um grupo especfico de mensagens ou todas mensagens.com
Publisher
e Subscriber usam frequentemente o padro Observer
.com
2
tipos de Publisher/Subscriber Fixo DinmicoPublisher/Subscriber Fixo
.com
Publisher/Subscriber Dinmico
.com
Normalmente
os Clientes no esto conectados diretamente no Barramento de MensagensCliente 1 Cliente 2 Cliente 3 Cliente 4 Cliente 5
Aplicao 1
Aplicao 2
Message BUSAplicao 3 Aplicao 4.com
3
Tipos de Publish/Subscribe List-Based
Publish/Subscribe Broadcast-Based Publish/Subscribe Content-Based Publish/Subscribe
.com
O
tipo do Publish/Subscribe impacta diretamente na arquitetura O barramento de mensagens Mantem uma lista de Published (Subjects) Mantem uma lista de Subscribers (Observers) Possui uma formatao comum das mensagens.com
List-Based Mantem
Publish/Subscribe
uma lista de Published Mantem uma lista de interessados (Subscribers) Mensagem recebida no barramento enviada apenas aos interessados (Subscribers)
.com
Broadcast-Based Mantem
Publish/Subscribe
uma lista de Published Mantem uma lista de Ns O barramento recebe uma mensagem e envia ela para todos os Ns Cada N precisa filtrar as mensagens que lhe interessa
.com
Content-Based As
Publish/Subscribe
mensagens so enviadas de acordo com um padro desejado Um Subscriber envia um comando contendo o padro/contedo de mensagens interessadas Identifica um ou mais campos A mensagem enviada para um Subscriber se ela combinar com seus interesses.com
Content-Based Realiza
Publish/Subscribe
um roteamento inteligente Depende de uma estrutura de alta performance Ler mensagens Analisar mensagens Rotear cada mensagem para os Subscribers
.com
.com
PontosO
negativos
problema deve depender da adio e remoo de sistemas Alto custo de infraestrutura Alto nvel de complexidade Necessita de uma equipe experiente Grande fluxo de mensagens Em sistemas pequenos adiciona latncia
.com
Pontos Em
positivos
Escalabilidade
grandes sistemas, normalmente, corresponde a alta performance Tolerncia a falha Decomposio de sistemas por responsabilidade Possibilidade de um sistema sobre demanda.com
Cliente 1 Cliente 2
Cliente 3
Cliente 4
Cliente 5
Cliente 6
Web Service (Home Broker)
Message BUS (Barramento de Mensagens)
Roteador de Ordens
Dados de Mercado Autenticao Autorizao (Market Data)
Gerenciador de Risco
Mercados BD Cassandra Memcached.com
Estrutura
Memcached
Aplicao
Retorna o valor cacheado
Consulta
No
Lgica da AplicaoSim No memcached? Colocar no Memcached?Resultado do Banco de Dados
MemcachedNo
BDSim .com
Grande
Throughput Analisar as possibilidades de escalabilidade Escalabilidade horizontal Escalabilidade vertical
.com
Aplicao 1
Aplicao 2
Aplicao 3
Aplicao 4 Aplicao 5
Aplicao 6 Aplicao 7
Message BUS
Grande ThroughputAplicao 8
Aplicao 9
Aplicao 10
Aplicao 11
.com
Aplicao 1
Aplicao 2
Aplicao 3
Aplicao 4 Aplicao 5
Aplicao 6 Aplicao 7
Message BUS
Message BUS
Menor Throughput
Menor Throughput
Aplicao 8
Aplicao 9
Aplicao 10
Aplicao 11
.com
Exemplo Grande
de uso no Mercado Financeiro
nmero de aplicaes/clientes Grande distncia entre as aplicaes/clientes Conexes dedicadas e de alta velocidade Objetivos
Diminuir custos
Diminuir a latncia Aumentar o throughput.com
Message BUS Market Data OMS ...
Message BUS
Message BUS Market Data OMS ...
Message BUS
Message BUS Market Data OMS ...
Message BUS
Message BUS Market Data
Message B Message BUS
Message BUS Market Data
Message BUS
Message BUS
BUS
Message BUS Market Data OMS ...
Message BUS
Existem
sistemas usados para auxiliar um Barramento de Mensagens RabbitMQ
http://www.rabbitmq.com/ http://www.rabbitmq.com/tutorials/tutorial -four-python.html HornetQ http://www.jboss.org/hornetq ZeroMQ http://www.zeromq.org http://zguide.zeromq.org/page:all#MissingMessage-Problem-Solver.com
Sistemas
usados para auxiliar o Barramento de MensagensAmazon SQS
Kestrel
http://robey.github.com/kestrel/ Existem muitas outras http://wiki.secondlife.com/wiki/Message_Q ueue_Evaluation_Notes Tipos de Queues: Pub/Sub, Multicast, Fan Out, http://lostechies.com/derekgreer/2012/03/ 28/rabbitmq-for-windows-exchange-types/.com
http://mikehadlow.blogspot.com.br/2011/04
/message-queue-shootout.html
.com
SUMRIO1. Arquitetura de Sistemas1.1. Orientado a Objetos 1.2. Cliente / Servidor 1.3. N-Tier / 3-Tier 1.4. Componentes 1.5. Domain Driven Design 1.6. Barramento de mensagens 1.7. Orientado a servios (SOA)
Referncias.com
Projeto5
de exemplo
camadas .NET (C#) Entity Framework (EF) WCF (Windows Communication Foundation) WPF (Windows Presentation Foundation) ASP .NET MVC Silverlight.com
.com
.com
.com
.com
.com
.com
.com
.com
.com
Pontos Fcil
Positivos
implementao Fcil manuteno Excelente opo para sistemas mais simples Fcil adaptao de diferentes BD Servios disponveis para vrios clientes
.com
Pontos Alto
Negativos
acoplamento entre camadas Contrato dos servios pouco flexveis Baixo desempenho em sistemas de baixa latncia (SOAP) Baixa escalabilidade Baixa tolerncia a falha
.com
SUMRIO1. Arquitetura de Sistemas1.1. Orientado a Objetos 1.2. Cliente / Servidor 1.3. N-Tier / 3-Tier 1.4. Componentes 1.5. Domain Driven Design 1.6. Barramento de mensagens 1.7. Orientado a servios (SOA)
Referncias.com
1.
GUTHRIE, S.; SOMASEGAR, S.; et al. Microsoft Application Architeture Guide. 2 Ed. 2009. Pginas 1 52. Disponvel em: http://apparchguide.codeplex.com/LARMAN, C. Applying UML and Patterns: Na Introduction to Object-Oriented Anlysis and Design and the Unified Process. 2 Ed. 2004. GAMMA, Erich. Padres de Projeto: Solues Reutilizveis de Software Orientado a Objetos. Porto Alegre: Bookman, 2005..com
2.
3.
4.
COULOURIS, G.; DOLLIMORE, J.; KINDBERG, T.; BLAIR, G. Distributed System: Concepts and Design. 5 ed. Addison-Wesley, 2012. Publish/Subscribe. Microsoft patterns & practices: proven practices for predictable results. http://msdn.microsoft.com/enus/library/ff649664.aspxMessage Bus. Microsoft patterns & practices: proven practices for predictable results. http://msdn.microsoft.com/enus/library/ms978583.aspx.com
5.
6.
7.
Architectural Patterns and Styles. http://msdn.microsoft.com/enus/library/ee658117.aspx Domain Driven Design and Development In Practice. http://www.infoq.com/articles/ddd-inpracticeDDD Introduo a Domain Driven Design http://www.agileandart.com/2010/07/16/dddintroducao-a-domain-driven-design/.com
8.
9.
10.
EVANS, E. Domain-Driven Design: Tackling Complexity in the Heart of Software. AddisonWesley Professional. 1 Ed. 2003.
.com
M e s s a g e B U S
M e s s a g e B U S M e s s a g e B U S Market Data OMS ...
M e s s a g e B U S
Professor: Augusto A. B. Branquinho. Email: [email protected] Blog: http://wpattern.com
.com