Escolar Documentos
Profissional Documentos
Cultura Documentos
SUMRIO
1. Arquitetura de Sistemas
1.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
.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
SUMRIO
1. Arquitetura de Sistemas
1.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
Coeso
.com
SUMRIO
1. Arquitetura de Sistemas
1.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
Exemplo
Web
muito comum
server
Difcil
escalabilidade
contexto
.com
Compartilhar
Peer-to-peer
Cliente/Servidor
Peer-to-peer
Mesma
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
SUMRIO
1. Arquitetura de Sistemas
1.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
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
3-Tier
.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
.com
Presentation
Layer
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
Caching Communication
Composition
Exception
Mais
.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
Authentication
Authorization Caching
Coupling
.com
Mais
.com
Data
Layer
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
Batching
Binary
Large Objects (BLOBs) Connections Data Format Exception Management Object Relational Mapping
.com
Data
Queries
Stored
.com
.com
Service
Layer
Interface
dos servios Tipos de mensagens Implementao dos servios Pode ser realizado separadamente
Service
Layer (consideraes)
Projetar
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
Service
Authentication Authorization
Communication
Exception
Service
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-
Projeto
de exemplo
Posts:
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
SUMRIO
1. Arquitetura de Sistemas
1.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
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
Dependncia
Factory 1 Factory 2
Dependncia
.com
Mercados
Plataforma 1
Plataforma 2
Plataforma 3
Market Adapter
Socket (TCP/IP)
Server Adapter
.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
SUMRIO
1. Arquitetura de Sistemas
1.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
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
.com
SUMRIO
1. Arquitetura de Sistemas
1.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
e consumo de mensagens
Baixo
.com
Problemas
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
.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
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
Aplicao 8
Aplicao 9
Aplicao 10
Aplicao 11
.com
Problema
.com
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
.com
.com
Publisher/Subscriber Dinmico
.com
Normalmente
Aplicao 1
Aplicao 2
Message BUS
Aplicao 3 Aplicao 4
.com
Tipos de Publish/Subscribe
List-Based
.com
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
Pontos
O
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
Roteador de Ordens
Gerenciador de Risco
Estrutura
Memcached
Aplicao
Consulta
No
Lgica da Aplicao
Sim No memcached? Colocar no Memcached?
Resultado do Banco de Dados
Memcached
No
BD
Sim .com
Grande
.com
Aplicao 1
Aplicao 2
Aplicao 3
Aplicao 4 Aplicao 5
Aplicao 6 Aplicao 7
Message BUS
Grande Throughput
Aplicao 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
nmero de aplicaes/clientes Grande distncia entre as aplicaes/clientes Conexes dedicadas e de alta velocidade Objetivos
Diminuir custos
.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 BUS
Market Data
Message BUS
Message BUS
BUS
Message BUS
Market Data OMS ...
Message BUS
Existem
.com
Sistemas
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
SUMRIO
1. Arquitetura de Sistemas
1.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
Projeto
5
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
SUMRIO
1. Arquitetura de Sistemas
1.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.aspx
Message 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-inpractice
DDD 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
.com