Arquiteturas Distribuídas - Apontamentos TSI · Sistemas de Micro-Kernel - Vantagens Alterações aos módulos em tempo-real Implica o recarregamento do novo módulo Sem necessidade

- Arquiteturas Distribuídas -

Rui Mendes Página 2 de 69

AULAS 1 E 2 – INTRODUÇÃO ....................................................................................................................................... 3

AULA 2 – MAIS SOBRE CLOUD COMPUTING .............................................................................................................. 18

AULAS 3 E 4 – SOA (SERVICE ORIENTED ARCHITECTURE) .......................................................................................... 28

AULAS 5 E 6 – ESCALABILIDADE E MODULARIDADE .................................................................................................. 55

AULA 7 – SEGURANÇA............................................................................................................................................... 63



Arquitetura de Sistemas

À medida que o tamanho e complexidade dos sistemas de software aumentam, o problema da conceção vai

além dos algoritmos e estruturas de dados da computação: conceber, desenhar e especificar a estrutura geral

do sistema emerge como um novo tipo de problema… Isto é a conceção ao nível da arquitetura de software.

Garlan, 1992

O que é Arquitetura de Software?

A arquitetura de software de um programa ou sistema computacional é a estrutura ou estruturas do sistema,

englobando componentes de software, as propriedades visíveis externamente desses componentes e as

relações entre eles.

(Bass et al, 2003)

O que nos diz este diagrama?

Vista de topo da arquitetura de um sistema de controlo para uma simulação acústica subaquática



Existem 4 elementos: CP, MODP, MODR, MODN

3 dos elementos devem ser mais semelhantes entre si do que com o CP

Todos os elementos têm um tipo de relação com os restantes

Resumindo: temos 4 componentes com ligações entre eles

Como uma arquitetura é um conjunto de componentes e ligações, então este é o esquema

de uma arquitetura.

Será?

São funções, processos, programas distribuídos, ou outra coisa distinta?

Quais as suas responsabilidades?

O que é que fazem?

Qual a sua função no sistema?

O que significam as ligações?

As ligações significam comunicação, controlo, envio de informação, invocação, sincronização,

partilha de informação sensível, …?

Quais os mecanismos de comunicação?

Que informação flui nesses mecanismos?

Natureza dos elementos?

A sua separação é significativa?

São executados em processadores distintos?

Correm em tempos distintos?

Representam formas de dividir o fluxo de tarefas?

Qual o significado do layout?

Porque está CP num nível separado?

Invocará os restantes elementos e os restantes não o poderão invocar?

Conterá os restantes elementos na sua implementação?

Questão estética?

Não haveria espaço na horizontal para colocar todos os elementos na mesma linha?

Então…

Vista de topo da arquitetura de um sistema de controlo para uma simulação acústica subaquática



Algumas definições de arquitetura e desenho de arquitetura

A arquitetura preocupa-se com a seleção dos elementos arquiteturais, a sua interação, os

constrangimentos e regras nesses elementos e nas suas interações… O desenho está relacionado com

a modularização e interfaces detalhadas dos elementos arquiteturais, dos seus algoritmos e

procedimentos, os tipos de dados necessários para suportar a arquitetura e para satisfazer os seus

requisitos. (Perry e Wolf,, 1992)

A arquitetura… é especificamente omissa … nos detalhes de implementações (algoritmos e estruturas

de dados). O desenho de arquitetura utiliza uma coleção mais rica de abstrações do que a conseguida

através de Desenho Orientado a Objetos (Monroe et al, 1997)

A arquitetura foca-se nas propriedades dos componentes de software visíveis externamente (Bass et

al, 1998)

Resumo:

A arquitetura não interessa a questão da implementação, se o sistema vai ser desenvolvido em python, C,

etc., não interessa as propriedades ou mecanismos internos de cada um dos módulos. Via interessar

perceber quais as interfaces que cada um dos componentes disponibilizará para outros comunicarem com

ele e do ponto de vista geral como é que todo o sistema vai comunicar entre os diferentes módulos e os

outros SI.

Como é que os dados são representados ou guardados não faz parte do ponto de vista de arquitetura.

Evolução

Arquiteturas centralizadas

Sistemas Monolíticos

Sistemas de Micro-Kernel

Arquiteturas distribuídas

Cliente-Servidor

P2P

Grid Computing

Cloud Computing



Sistemas Monolíticos

Sistemas autocontidos

Entrada de dados

Saída de dados

Processamento

Gestão de erros

Interface de utilizador

Podem ser executados em modo batch (automático/semiautomático) ou mediante pedidos de

utilizador (interface)

Os dados são carregados em memória e gravados em momentos conhecidos

Pode suportar concorrência

Acesso por múltiplos utilizadores simultaneamente é complexo e não garantido

Sistemas monolíticos - Vantagens

Performance

Acesso a informação - depois de carregados, os dados estão em memória

Alteração – edição em memória

Simplicidade

Estrutura mais simples

○ Menos código? Não necessariamente…

Menos problemas “difíceis”

○ Locking, transações, integridade, performance, concorrência, …

Sistemas monolíticos - Desvantagens

Acesso por vários utilizadores

Alterações e manutenção de sistema

Aplicações críticas – quanto tempo poderão estar paradas?

Tempo de “carregar”

Toda a informação tem que ser carregada para memória

○ Podem-se implementar mecanismos de carregamento seletivo, mas já vai

complicar…

Sistema Monolítico

Entrada e Saída de dados

Processamento dados Gestão de Erros

Interface Utilizador



Sistemas de Micro-Kernel

Mais comum em sistemas operativos

No entanto a filosofia deste pode ser adaptada a outros cenários

Lógica central, altamente generalista

Define as regras gerais e formas de efetuar operações

Módulos carregados dinamicamente

Extensíveis

Costumizáveis

Robustos (em teoria)

Confiáveis (em teoria)

Proteção (vários níveis)

Tolerância a falhas

Segurança

Sistemas de Micro-Kernel - Vantagens

Alterações aos módulos em tempo-real

Implica o recarregamento do novo módulo

Sem necessidade de parar o programa principal

A lógica deste sistema pode ser combinada com outros para dar origem a sistemas bastante flexíveis

Sistemas de Micro-Kernel - Desvantagens

Potencial complexidade do kernel

Necessidade de maior rigor e controlo

Interfaces

○ Comunicação

○ Acesso

Integridade

○ Até que ponto poderão as ações de um módulo afetar outro(s)?

É necessário que cada um destes módulos seja bem projetado

Processamento dadosProcessamento dados

Gestão de ErrosGestão de Erros

Entrada e Saída de dadosEntrada e Saída de dados

Sistema

Interface UtilizadorInterface Utilizador



Cliente-Servidor

Mais conhecido a nível de aplicações (Web)

Acesso de vários utilizadores em simultâneo

Usando um ou mais clientes

Cliente e servidor podem existir no mesmo sistema

Tipicamente este não é o caso

Cliente-Servidor - Vantagens

Dados armazenados nos servidores

Possibilidade de backups centralizados

Flexibilidade de serviços

Possibilidade de migração de serviços entre máquinas sem que os clientes se apercebam

Manutenção

Uma única atualização permite servir inúmeros clientes (ou todos, em alguns casos)

Segurança

Os servidores podem ser armazenados em locais controlados

Pontos de acesso aos serviços podem ser focalizados e vigiados

Redundância

É possível escalar o serviço, aumentando a disponibilidade, sem que os utilizadores se

apercebam

Cliente-Servidor - Desvantagens

Se não for bem “pensado”, o sucesso do sistema pode ser o seu maior inimigo

O número de clientes a pedir serviço pode ultrapassar a capacidade do serviço

Peer to Peer

Cada nó na rede é (pode ser) simultaneamente cliente e servidor

Peer to Peer - Vantagens

Escalável

Quantos mais nós, mais recursos

Redundância

Servidor ClienteCliente

Cliente

Cliente



Peer to Peer - Desvantagens

Manutenção

Cada atualização tem que ser replicada por todos os nós

Dados não são armazenados centralmente, pelo que backups automatizados de toda a rede P2P

seria um processo moroso.

Grid Computing

Sistema distribuído

Controlo central de processos

Processamento intensivo

Armazenamento

Tipicamente meio académico

Computação como Serviço

Utility computing

Água, luz, gás…

CERN

SETI@Home

Folding@Home

World Community Grid

...

Grid Computing - Vantagens

Gestão descentralizada dos nós

Acesso ao sistema estandardizado

Pontos de acesso conhecidos

Protocolos de comunicação standard

Otimizado para HPC (High Performance Computing)

Uma única tarefa pode necessitar de todos os nós ativos

Grid Computing - Desvantagens

APIs de integração de módulos são bastante específicas

Manutenção do sistema (existente em vários datacenters e casas particulares)

Tipicamente apenas processos batch são executados

Processamentos longos

Maior dificuldade de escalonamento de recursos

Sistema de Grid

Nó Grid

Nó Grid

Nó Grid

Nó GridNó de

Controlo

Nó Grid

Ponto de

AcessoCliente

Cliente

Cliente



Cloud Computing

Semelhante a Grid (foi inspirado nele)

Trata-se de uma arquitetura

Permite executar máquinas virtuais nos seus nós

Constituída por 3 camadas lógicas

IaaS

PaaS

SaaS

Cloud Computing - Vantagens

Facilidade de escalar serviços

No Natal, as compras na sua loja online disparam? Então nada como scale-up apenas

durante esse período!

Possibilidade de ter não só serviços como sistemas operativos completos

Preço de acesso

“Pay as you go”

Flexibilidade de escalonamento de serviços

Cloud Computing - Desvantagens

Possível “vendor lock-in” (Principalmente no SaS)

Preço de acesso

Pode tornar-se caro

○ Mas se se torna caro é porque há muitos recursos em uso!

Deve-se analisar o Total Cost Ownership envolvido (ter os recursos no DataCenter privado ou

outsourcing)

Copyright e direitos legais são ainda matéria complexa



Estratificação de arquiteturas

Arquiteturas 1 camada

Interface, lógica de negócio e armazenamento estão integrados

Expansão e alteração complexas

Arquiteturas 2 camadas

Interface + lógica separado de armazenamento

Interface separados de lógica + armazenamento

Clara distinção entre camadas

Atualização de uma camada não interfere com a outra

Desde que se respeitem as interfaces públicas!

Arquiteturas 3 camadas

Interface, lógica de negócio e armazenamento estão

conceptualmente separados

Possibilidade de alteração e/ou expandir cada uma das

camadas de forma independente



Arquiteturas n-Camadas

Várias camadas independentes

Pode ser vista como uma especialização do modelo 3 camadas

Permite um grau mais detalhado de independência entre módulos do sistema

Arquiteturas Orientadas ao Serviço

Composta por serviços distintos

podem ou não existir no mesmo espaço geográfico (mesmo computador)

○ Não confundir com camadas de aplicação do mesmo programa

Cada serviço é independente dos restantes

Cada serviço tem/pode ter a sua própria arquitetura!

Arquitetura distribuída

Invocação de serviços

CORBA (Common Object Request Broker Architecture)

RMI (Remote Method Invocation)



Web Services

○ SOAP

○ REST

○ XML

○ JSON

Independência total

Evolução (cada bloco pode evoluir isoladamente)

Linguagem de programação

Sistemas operativos

Altamente escalável (com load balancer p.e.)

Reutilizável (podem ser utilizados para diversas funções)

Reconfigurável

Configurações dinâmicas

Orquestração

Coreografia de serviços

BPEL

UDDI

Um apanhado de estilos e padrões de arquitetura

Blackboard

Client–server model (2-tier, n-tier, peer-to-peer, cloud computing all use this model)

Database-centric architecture

Distributed computing

Event-driven architecture

Front end and back end

Implicit invocation

Monolithic application

Peer-to-peer

Pipes and filters

Plugin

Representational State Transfer

Rule evaluation

Search-oriented architecture (A pure SOA implements a service for every data access point.)

Service-oriented architecture

Shared nothing architecture

Software componentry

Space based architecture

Structured (module-based but usually monolithic within modules)

Three-tier model (An architecture with Presentation, Business Logic and Database tiers)

N-tier model

Aspects oriented architecture



O arquiteto de sistemas

Influência dos stakeholders no arquiteto

Princípios e boas práticas

Architectural Description Languages

Tipicamente UML

Há mais… ACME, Rapide, etc

Método formal e sistemático de representação de arquiteturas

Devem poder ser interpretadas por computadores e humanos

Tal como a arquitetura em si, é independente da tecnologia e linguagem de programação

Documentação de Arquitetura

Modelo, vistas e estruturas

Não esquecer:

“A arquitetura … é a estrutura … englobando componentes …, as propriedades visíveis … e as

relações entre eles”

Moral da história: é complicado tentar mostrar toda a arquitetura de um sistema apenas

num desenho bidimensional

Escolha das vistas a representar

Uma vista é a representação de um conjunto coerente de elementos arquiteturais, tal como

definido e interpretado pelos stakeholders

Adicionar informação ad hoc que não possa ser incluída nas vistas e que seja pertinente para a

interpretação correta da arquitetura (notas, argumentos, …)

Uma estrutura é o conjunto de elementos representados nas vistas



Software

Hardware

Estruturas de Módulo

Como deve o sistema ser estruturado em termos de unidades de código (módulos)?

Estruturas de Componente/conector

Como deve o sistema ser pensado em termos de comportamento em execução

(componentes) e interações (conectores)?

Estruturas de Alocação

Como se relaciona o sistema com estruturas não software (i.e., CPUs, sistemas de ficheiros,

rede, equipas de desenvolvimento, etc.)?

Estruturas de Módulo

Representação de unidades de implementação

Responsabilidade funcional

Que outros módulos pode este usar?

Com que módulos este se relaciona?

Herança, etc

Estruturas de Componente/conector

Como é que o sistema funciona?

Quais são os componentes principais na execução?

Quais as fontes de dados?

Que componentes poderão ser paralelizáveis?

Como é que a informação flui?

Estruturas de Alocação

Relações entre os elementos de software e elementos de sistemas externos

Qual a equipa de desenvolvimento responsável por determinado módulo?

Em que ficheiros são os elementos armazenados em cada uma das fase do ciclo de vida do projeto?



Que estruturas não descurar?

Módulo

Componente/conector

Concorrência e distribuição de funcionalidade

Desenvolvimento

Organização de módulos

bibliotecas

Subsistemas

unidades de desenvolvimento (fases de desenvolvimento)

Deployment

Informação sobre execução e mecanismos de comunicação

Modelação de arquitetura Exemplos de relações e notação em UML

Módulo B é parte do módulo A, módulo D depende do módulo C, e o módulo F é do tipo do módulo

E.



Decomposição e reutilização

Módulo

Unidade de implementação

Padrão

Comportamento repetitivo manifestado em diversos cenários, na implementação de um ou

mais módulos

A deteção de padrões é responsabilidade não apenas do arquiteto, mas também das equipas

de desenvolvimento

Reutilização

Capacidade de reaproveitar padrões em diversos cenários

Generalização

Capacidade de extrapolar padrões para ambientes diversos do original

Desenho de padrões

Não reinventar a roda!

Reutilizar soluções já conhecidas e de qualidade para problemas recorrentes

Estabelecer terminologias comuns para melhorar a comunicação inter e intra equipas

Padrões conhecidos

Gang-of-four

○ http://www.dofactory.com/Patterns/PatternAdapter.aspx

Refatorizar

Constantemente alterar e adaptar implementações para que seja mais fácil de interpretar e

simples de alterar



... a bit of history...

Prior to 1960 – Huge machines (e.g. ENIAC) – Only governments could afford computers

the 60's – Computer use developed commercially and was shared by multiple parties – The mainframe era

the 70's – The age of the microprocessor (1971 - Intel releases the 4004) – First commercial data networks

the 80's – IT operations grow in complexity and microcomputers are now split between the Personal

Computer and the Server the 90's

– The Internet gained immense popularity. – Companies required fast internet connectivity and nonstop operation to deploy systems and

establish a presence on the Internet. the millenium

– A fast growing Internet based economy required mass deployments of Servers with fast Internet access.

– The rebirth of the DataCenter

Dot.com bubble burst

The aftermath...

dot.com companies built overcapacity

– Datacenters full of computational capacity

– Democratization of broadband access (companies and individuals)

Cloud computing pioneers

– Salesforce.com

• Provides CRM application over the browser

• Low cost access over the Web to a previously unaffordable service

– Amazon Web Services



• In 2002 offers online storage service (S3)

• In 2006 launches Elastic Compute cloud (EC2)

Anyone could rent capacity and build/sell their services online.

....REWIND

Cloud Computing Precursors

Client-Server Model: Distributed applications which distinguish between providers (or servers), and

clients

Grid Computing: A virtual computer, composed of a cluster of networked, coupled computers (in

order to perform larger tasks).

Peer-to-Peer: Participants are both suppliers and consumers, using distributed architecture without

the need for centralization

Service Oriented Computing: Like cloud computing, this service-oriented version implements

computing techniques, leveraging software-as-a-service

– source: http://tinyurl.com/cjaol8a

Cloud Computing

New and smaller companies could not reach large audiences without building their own datacenter,

but…

Running a DataCenter is expensive

– Costs to much to built (real-estate, servers, network equipment, HVAC)

– Costs to much to run (energy, connectivity, network administration, systems management,

replacements, … )

There is a need to adapt existing capacity and resources to it's uses

– You hardly need an entire datacenter (or even a server) when deploying a first production

grade system prototype

What is Cloud Computing?

Service Oriented access to distributed computational, storage and network resources

Elastic resource provisioning

– Ability to upgrade AND downgrade computational and network resources

Software defined computational resources

– Virtualization technologies enable Cloud Providers to soft-define computational and network

resources

API based provisioning



– All provisioning aspects are handled programatically through a API (lowering costs associated

with admin staff)

Computing utility - Pay per use

– Pay only for what you use (no CAPEX)

Instant Scalability

– Instant deployment of new resources as requested

Reliability

– Professional management of hardware resources, 24h support

Efficiency

– Efficient use of resource, through large economies of scale

Typical granted access divided on layers

– Infrastructure as a Service (IaaS)

– Platform as a Service (PaaS)

– Software as a Service (SaaS)

There is no requirement for providing (or even using!) all layers

IaaS – Infrastructure as a Service (I)

Service access to virtualized servers, storage & networks

– E.g. Amazon (EC2, S3, EBS), Rackspace

Access to infrastructure stack:

– Full OS access

– Storage

– Routers

– Load balancing

Advantages

– Pay per use

– Instant Scalability

– Security

– Reliability

– APIs



Examples

The closest to the hardware layer made available on Cloud Computing

Abstracts and virtualizes the hardware layer

– Required by the other layers

– Provides an homogeneous platform from which to grow

“Oldest” layer available, so pretty much stable in terms of VMs migration. Stable, but not standard:

– According to E.G. Nadhan, standardization is somewhere between Discovery and Experience.

– Consensus, Simplification and Governance are on the far horizon

– http://tinyurl.com/d96axyo (12-22-2011)

IaaS – Virtualization

IaaS is made possible thanks to recent developments in virtualization technologies

Virtualization is a technique allowing to run several different systems in the same hardware, in a

totally separated manner.

Virtualization allows a single computer to play the role of several computers, through sharing

hardware resources to multiple environments.

Virtualization benefits: resource consolidation, security, encapsulation, homogenization, hardware

independence

Virtualization drawbacks: best effort availability, vendor lock in, poor I/O performance, overcommit

scenarios

PaaS – Platform as a Service

The abstraction of applications from traditional limits of hardware allowing developers to focus on

application development and not worry about operating systems, infrastructure scaling, load

balancing and so on.

– Examples include Google App Engine (Java, Python), MS Azure (.net), Heroku (RoR)

Platform delivery model

– Platforms are built upon Infrastructure, which is expensive

http://tinyurl.com/d96axyo



– Estimating demand is not a science!

– Platform management is not fun!

Advantages

– Pay per use

– Instant Scalability

– No sysadmin tasks

– Better Security

Examples

Usually consists of specially crafted software development kits (SDKs)

SDK enables applications to be aware of the cloud’s capabilities

– Ex.: scaling applications, controlling costs, etc.

Not so much standardized as IaaS, so standards de facto are used by some providers

– Several providers support migration from/to major providers

– Possible vendor lock-in may occur

SaaS – Software as a Service

Software-as-a-Service: Applications with a Web-based interface accessed via Web Services and Web

2.0.

– E.g. Google Apps, SalesForce.com and social network applications such as FaceBook

Software delivery model

– Increasingly popular with SMEs

– No hardware or software to manage

– Service delivered through a browser

Advantages

– No installation required

– Not platform specific



– Automatic upgrades

– Access your data anywhere

Examples

Typical solutions provide multi-tenancy

– Make it once, use it multiple times solutions

– Client customizable solutions

– One single running instance

Benefit from being deployed over the PaaS

– Can control the horizontal scaling (add/remove more processing nodes)

Typical access is done from thin clients or web browser

Anything as a Service (XaaS) (X as a Service)

IaaS, PaaS and SaaS are the original service layers, however…

Database as a Service, is one of the most commonly referred services

There’s more:

– Storage as a Service, Communications as a Service, Monitoring as a Service, ….

Cloud Provisioning Models

Public

Endorse the pay-as-you-go model

No upfront commitment, no maintenance

Computing as a true utility (just like water or gas)

– The more you use… the more you pay!

The computational limit is in your pocket (i.e. your credit card)



Private

Suitable on computational communities and companies

Big upfront commitment (Datacenter, hardware, licenses, …)

Fixed costs (IT Team, electricity, …)

Maintenance costs (hardware upgrades, …)

The computational limit is in the amount and usage of the facilities (just like the public cloud,

however, these are typically smaller)

Hybrid

Small Datacenter for every day operations

When scaling is required, reach for public providers

Grid Computing vs Cloud Computing

Grid Computing Cloud Computing

• Typical usage: batch scheduled execution of

long running operations

• Specific programming languages

• Mostly research scenarios

• Enables utilization of resources

• Accessible for some

• Typical usage: deployment of services for

clients

• Fairly common programming languages

• Mostly business scenarios

• Enables virtualization of resources

• Accessible for everyone



Moving to the Cloud?

Things to consider before moving to the cloud (1)

Estimate the application’s resources usage

Estimate the application’s growth requirements

Calculate the Total Cost of Ownership (TCO) for the application

– On a cloud provider

– On a regular hosting provider

– On your own Datacenter (if applicable)

Review the SLA of the cloud providers

Analyze the impact of outsourcing your business data

– And your users data!

Is there sensitive/personal data?

– In terms of data protection, what is the provider’s policy?

Are there any copyright issues?

Which law should be applied to your data?

– Cloud providers are available worldwide, capable of backing up data on geographically

different sites

– Service providers and Cloud providers may be of different countries

– Users and Service providers may be of different countries

– Depending on the countries’ rules, legislation on personal user data registration may differ

– More interestingly:

“Our data flows around in thousands of clouds, in deeply encrypted forms, ready to be used when

necessary. Earth bound nodes that transform the data are as deeply encrypted and reboot into a

deadlock if not used for 8 hours.

All attempts to attack The Pirate Bay from now on is an attack on everything and nothing. The site

that you're at will still be here, for as long as we want it to. Only in a higher form of being. A reality to

us. A ghost to those who wish to harm us.” http://thepiratebay.se/blog/224, 17th nov 2012

Cloud Computing - Pros

Lower cost of ownership

Reduce infrastructure management responsibility

Allows for unexpected resource loads

http://thepiratebay.se/blog/224



– During Christmas, purchases on your online shop skyrocketed? Scale-up the application only

during the peak season!

Faster application rollout

May provide not only services, but full blown operating systems

– With integrated backups

How does cloud economy work ?

– Multi-tenant

– Virtualization lowers costs by increasing utilization

– Economies of scale afforded by technology

– Automated update policy

Usage price

– Utility model, “Pay as you go”

Cloud Computing - Cons

Possible vendor lock-in

Usage price

– May become expensive

• But that means more resources are in use, which may be a good sign… unless poorly

configured!

– Should analyze the TCO

Copyrights and legal obligations are still a complex subject

When it rains, it pours!

– Remember the day Amazon crashed? 21st April 2011

• Reddit, Foursquare, GitHub, Indaba, etc…

• 24h+ outage on some sites

• 0,07% of irrecoverable data on one availability zone – multiply by a few thousands of

clients and…

– Remember the day Azure crashed? 29th February 2012

• About 10 hours outage worldwide

• No data loss

• Leap day bug on certificates issuing

Research Trends (I)

Standardization on PaaS layer



– How to prevent vendor lock-in?

– Can we endorse a transparent PaaS? Or is it better to use transversal PaaS switchers?

– Why do we need to understand the cloud’s insights? Do we need to understand the web

server’s insights?

Usage Optimization Models

– How to optimize cloud providers usage?

– How to optimize clients’ cloud usage?

– How to minimize costs?

– What is the impact of using a GPU-based cloud solution?

Multiple Clouds Usage

– Sky computing – deploying your software over multiple providers

– Cloud bursting – deploying your software internally and externally, if required

– Automatic selection over …

• best price/conditions

• estimated cloud usage

• External resources are seen as your own, for your clients

Volunteer Cloud Computing

– How to explore the idle resources outside the datacenter?

– Can we use your computer? Xbox? PlayStation?

Security

Disaster scenarios



“A distributed system is one in which the failure of a computer you didn’t even know existed can render your

own computer unusable.”

Leslie Lamport

Orientada ao Serviço

Definição

Acrónimo para “Arquitetura Orientada a Serviços”

Não é uma tecnologia, mas sim um paradigma de utilização de sistemas

Advoga a exposição de lógicas de negócio na web, como forma de gerar novas receitas e

aproveitar novos mercados

É uma abordagem que tem estado em voga, devido à rede global e a integração de serviços e

sistemas

Trata-se de um modelo de arquitetura cuja meta é aumentar a eficiência, agilidade e produtividade

relativamente a paradigmas anteriores, focando em serviços os meios pelos quais é representada a

lógica de negócio

http://www.youtube.com/watch?v=sbd_1G8Kqjs

http://www.youtube.com/watch?v=sbd_1G8Kqjs



Para que serve o SOA?

Dar maior relevo a produtos (lógicas) comerciais de empresas

“Alavancar” um modelo de negócio

Permite que uma dada empresa se concentre na sua área de especialização, podendo usar

serviços disponibilizados por outros

Criar melhores sistemas, desenvolvidos sobre serviços já testados

SOA – Princípios gerais e boas práticas

Reusabilidade

os serviços disponibilizados poderão ser potencialmente reutilizados noutros cenários

Granularidade

sendo específicos o suficiente para a resolução do problema

Modularidade

auto-suficientes, no sentido em que o serviço possa ser entendido como um módulo que

processa de forma independente e autónoma uma dada instrução

Composabilidade e Componentização

suportar composição de serviços mais elaborados, usando para tal os próprios serviços como

componentes orquestrados ou encadeados numa dada sequência

Adesão a standards

permite maximizar as potencialidades de interoperabilidade do serviço com outros.

Identificação e categorização de serviços, provisionamento, entrega, monitorização e

acompanhamento

os serviços em produção deverão ser corretamente identificados e categorizados, de forma a

facilitar a tarefa (manual ou automatizada) de pesquisa e retorno do serviço correto para

uma dada operação

SOA – Princípios específicos

Encapsulamento

O serviço é visto como uma “caixa negra”, onde o importante, do ponto de vista de utilização

do mesmo é saber quais os dados esperados à entrada, e qual o resultado esperado à saída.

Separação da camada de negócio da tecnologia de base

uma vez que o serviço está abstraído numa caixa negra, é em qualquer instante possível

alterar a tecnologia base, mantendo a lógica de negócio.

Implementação única e vista global de componentes



Corolário dos princípios gerais, visto que se os serviços devem ser reutilizados em serviços

cada vez mais complexos, então estes deverão ter implementação única na empresa/meio

onde serão usados, estando ao mesmo tempo visíveis e disponíveis para composição de

outros serviços.

Reaproveitamento de lógicas existentes sempre que possível

se for possível adaptar um serviço para ser interoperável quando até então servia apenas

uma aplicação, é uma abordagem que ganha todo o tempo de desenvolvimento da fase de

operação com uma única aplicação.

Serviços vagamente unidos – loosely coupled services

Os serviços dependem de si em primeiro lugar, mas para poderem comunicar com outros,

dependem dos manifestos ou contratos destes

Os contratos indicam o que o serviço necessita para funcionar (parâmetros de entrada) e o

que retorna no final da execução,

Gestão do ciclo de vida

Tal como em qualquer sistema em produção, será necessário gerir o ciclo de vida do serviço.

Uso eficiente de recursos do sistema

Cenários de interoperabilidade conferem um potencial de maior utilização dos serviços

disponibilizados, estes deverão acautelar questões de desempenho e escalabilidade da

operação para casos de elevada utilização.

Maturidade e desempenho do serviço

Os serviços disponibilizados deverão estar já num ciclo de vida de produto que permita

garantir a sua robustez e desempenho.

Serviço

Um serviço é uma unidade autónoma que não dependente da plataforma, e que pode ser publicado,

descoberto e agregado a outros de novas formas, não necessitando de contextos ou estados de

outros serviços para satisfazer a sua função

pode, contudo, invocar outros serviços como parte do seu processo de execução

Qualquer componente lógico de uma aplicação pode ser transformado num serviço usável em rede

Serviço de reserva de bilhetes apenas disponível numa aplicação de call center pode

rapidamente ficar disponível na web, em diversas aplicações e cenários



Encadeamento de serviços

Orquestração

Considerando os serviços como unidades de processamento bem definidas através de manifestos ou

contratos é possível encadear vários serviços, criando assim novos serviços de possivelmente maior

valor

Tal como numa orquestra, também em SI podemos coordenar, ou orquestrar.

BPEL – business process execution language – é o standard de orquestração

Explicando graficamente

Livraria online

Empresa financeira

Utilização de serviços

Dependendo da natureza da prestação do serviço, podem ser necessários mecanismos que

garantam:

Confiança

○ A empresa XPTO confia nas informações que lhe são prestadas pela empresa ou

aplicação ABCD

Não repudiação

○ A empresa ou aplicação ABCD é responsável pelas informações dadas, e é garantida

a autenticação desta perante o serviço

○ Esta autenticação permite à empresa fornecedora efetuar desde registo de

operações até contabilidade e faturação sobre as mesmas



○ Exemplo de serviços com esta lógica: amazon.com

Da teoria à práctica

Como se passa de um modelo conceptual SOA para a prática?

O uso de web-services tem sido o mais recorrente para colocar um modelo de SOA em

prática

Web-Services

Encapsulados em envelopes SOAP

Baseados em XML

○ Esquemas standard

Definem contratos de utilização do serviço

○ WSDL – web service definition language

○ Especifica o que é esperado à entrada e qual o tipo de resultado esperado

SOA na UA

http://api.web.ua.pt

Diretório de serviços

○ UA

○ SAPO

○ PTInovação

○ Disciplinas

SOA no Sapo

https://store.services.sapo.pt/pt/Catalog

https://store.services.sapo.pt/pt/Catalog



Potencialidades de SOA - exemplos

Integração de informação de forma distinta

Mashups

www.dipity.com

http://www.openmashup.org/omadocs/v1.0/index.html

Vista de processo de negócio

Definição

Por processo de negócio entende-se qualquer atividade cujo objetivo seja a de satisfazer uma

necessidade ou desejo de um participante

Intervenientes

Um interveniente é uma entidade individual humana ou não humana ou um aglomerado de

entidades que tenha um interesse no estado do serviço ou no resultado do uso do mesmo.



Participante

Interveniente que interage no processo

O interesse primário está no uso bem-sucedido de serviços

Não participante

Intervenientes que não interagem no processo

Podem ser afetados pelo uso ou provisionamento de recursos

Podem ter interesse no resultado do processo

○ Aplicação de taxas, por exemplo

Fornecedor de serviço

Trata-se de um participante que oferece um serviço que pode ser usado por outros

Consumidor de serviço

Trata-se de um participante que necessita de interagir com o serviço para aceder a algo que

este fornece

Agente

Entidade capaz de agir em nome de uma pessoa ou organização

É necessário para que os participantes possam oferecer, consumir e de uma forma geral

participar no processo

Exemplos: Aplicações de software, dispositivos de hardware, ...



Ciclo de vida de serviço



O que não é

O que é

Semelhante ao ciclo de vida de produto

Identificação, Especificação, Modelação, Desenvolvimento, Pré-produção, produção,

Avaliação e … Identificação.

Foca-se nos aspetos de

Interoperabilidade

Composição

Reutilização

Deve ter em consideração também o fim de ciclo: o que acontece ao serviço quando já não se afigura

necessário?

Ciclo de vida



Tipos de desenvolvimento de serviço

A semelhança de qualquer aplicação, há várias formas de desenvolvimento.

Code-first

Contract-first

Code-first

Desenvolvimento das funcionalidades em primeiro lugar

No fim, adequa-se a integração como serviço

Ou seja, faz-se o código e no fim geram-se os contratos

Vantagens

up and running mais depressa?

Contract-first

Especifica-se como o serviço interage em primeiro lugar

Depois, preenchem-se os espaços em branco com código

Ou seja, geram-se os contratos primeiro e só depois o código

Vantagens

possibilidades de integração a partir do momento de especificação?



Code-first vs contract-first

O que está em questão?

Saber como resolver as questões de interoperabilidade

O que vai ficar nas mãos de ferramentas de tradução?

A especificação do contrato?

A geração de um stub a partir do contrato?

Até que ponto as ferramentas podem ajudar?

Referências

http://www.oracle.com/technetwork/articles/entarch/soa-service-lifecycle-design-096035.html

Comunicação entre módulos

CORBA? Popular em tempos

○ Implementações em Windows e Linux (tipicamente JAVA e C++) Problemas de APIs, segurança, concorrência, etc.

DCOM? Problemas semelhantes a CORBA

RMI? Específico de JAVA

Web-services! SOAP

○ Envelopes de XML REST Independentes da linguagem

Web-Services

Tipicamente disponibilizados como informação em XML

Envelopes SOAP

Comunicados via http

SOAP (Simple Object Access Protocol)

Encapsula informação a ser comunicada na rede

A comunicação entre aplicação e serviço é normalmente feita usando protocolos como HTTP ou

HTTPS, mas pode também ser feita com outros (SMTP, por exemplo)

http://www.oracle.com/technetwork/articles/entarch/soa-service-lifecycle-design-096035.html



A vantagem do HTTP e HTTPS é que passam com maior facilidade por firewalls

A maior desvantagem é que o SOAP é também ele XML, pelo que uma mensagem simples

pode ficar bastante maior quando passada na rede

WSDL (Web Service Description Language)

Descreve as funcionalidades disponíveis no web service:

Métodos

Argumentos de entrada

Valores de retorno

É no fundo o que explica o que a “caixa negra” faz

É um contrato que vincula o consumidor e fornecedor do método, em termos de troca de dados

Podem ser usados por ferramentas que geram o código para acesso ao web-service de forma

automática

REST (REpresentational State Transfer)

Apresentado na tese de doutoramento de Roy Fielding

Um dos autores do HTTP (rfc2616 )

Outra forma de usar recursos (resources) de servidores remotos

Tudo são recursos

Cada recurso tem um URI único

Interface uniforme para manipular os recursos

Como protocolo

Stateless

Cacheable

○ Podem ser guardadas versões do recurso durante a sua transferência pela rede

Uma página Web é um recurso REST

A forma da página, é uma representação desse recurso

Em REST, um recurso pode ter várias representações

É o cliente que pede uma representação específica, de acordo com as disponibilidades do

servidor

O estado do recurso é transferido do servidor para o cliente e vice-versa

É mais “limpo” que SOAP

REST

WS

POST /generic_message_handler



POST /purchase_orders HTTP/1.1 Host: accounting.mycompany.com content-type: application/purchase-order+xml .... <po>...</po>

content-type: application/SOAP+XML <soap:envelope> <soap:body> <submit-purchase-order> <destination>accounting.mycompany.com</destination> <po>...</po> </submit-purchase-order> </soap:body> <soap:envelope>

WADL (Web Application Description Language)

Semelhante a WSDL, mas tipicamente usado com serviços REST

Trata-se de uma proposta da SUN que não passou para norma W3C

http://www.w3.org/Submission/wadl/

“As of today, W3C has no plans to take up work based on this Submission.” (W3C,

2009/10/14)

Uma das questões levantadas é da real necessidade de sua existência

○ http://bitworking.org/news/193/Do-we-need-WADL

JSON (JavaScript Object Notation)

Também pode ser lido como “Jason”

Formato mais simples que XML para intercâmbio de informação

À semelhança de XML

permite ser lido tanto por máquinas como por humanos

É independente da linguagem e/ou arquitetura do sistema

JSON – Tipos de dados

Duas estruturas

Objeto

○ Coleção de pares nome/valor

Lista de valores

Objeto

Conjunto não ordenado de pares nome/valor

{ “nome” : valor , “nome1”:valor1, ... }

Lista ou array

Coleção ordenada

[ valor , valor1, valor2, ... ]

http://bitworking.org/news/193/Do-we-need-WADL



JSON – Tipos de valor

Texto -> “txt”

Número -> 123

Objeto -> { ... }

Array -> [...]

Verdadeiro -> true

Falso -> false

Nulo -> NULL

JSON – esquematização lógica

object

{}

{ members }

members

pair

pair , members

pair

string : value

array

[]

[ elements ]

elements

value

value , elements

value string

number

object

array

true

false

null

JSON vs XML – Tipos de dados

JSON XML

Tipo de dados escalares nativos como base

Dados estruturados

Arrays

Todos os tipos de dados são definidos via

um esquema



objetos

Hierarquia de tipos de dados

JSON vs XML – Suporte de listas

JSON XML

Suporte nativo

Um array tem que ser especificado no schema,

tipicamente por intermédio de um elemento exterior

que permite que os filhos sejam repetidos

JSON vs XML – Suporte a objetos

JSON XML

Suporte nativo Um objeto tem que ser definido no schema, por

intermédio de elementos e atributos



JSON vs XML – Nulos

JSON XML

Suporte nativo Através de xsi:nill (e importação de respetivo

namespace)

JSON vs XML – Comentários

JSON XML

Não suportados Sim

JSON vs XML – namespaces

JSON XML

Não existe esse conceito

Colisões de nomes iguais são tratadas com prefixos

nos nomes: “carro.cor”

Suporte nativo

JSON vs XML – tamanho

JSON XML

Formato simples e compacto

Formato mais textual

Pode ser mais extenso, principalmente nas listagens

de elementos



JSON vs XML – uso em Javascript

JSON XML

É baseado na sintaxe do JavaScript, pelo que não é

necessário nenhum parser extra

Requer um parser de XML DOM (Document Object

Model)

Necessita de código extra para passar de XML DOM

para objetos JavaScript

JSON vs XML – curva de aprendizagem

JSON XML

Conceitos simples, acessíveis a quem tenha já

conhecimentos de JavaScript ou outras linguagens

semelhantes

XPath

XML Schema

XSLT

XML Namespaces

DOM

...

JSON vs XML – exemplos

Exemplo1

JSON XML



Exemplo2

JSON XML

JSON em JavaScript



Segurança e confiança em arquiteturas distribuídas

Que garantias tenho sobre o serviço que estou a usar?

Acesso aos meus dados?

Adulteração dos meus dados?

Que garantias tem o serviço sobre quem o está a invocar?

Acesso aos dados?

Alteração? Introdução?

Tempo de processamento?

Espaço de armazenamento?

Web–Services: Segurança e confiança

Segurança

Comunicações cifradas

Autenticação de ambos os intervenientes através de certificados digitais

WS-Security e WS-SecurityPolicy

Confiança

WS-Trust



SAML

Diretório de serviços

UDDI (Universal Description, Discovery and Integration)

Serviço externo aos web services

As “páginas amarelas” dos WS

Permitem o registo e pesquisa de web services (através de web-services)

Dados

BusinessEntity

BusinessService

BindingTemplate



UDDI



UDDI - vivo ou morto?

Não é relevante

O conceito subjacente é importante

UDDIs e alternativas

Apache Java UDDI aka jUDDI (Maio 2011)

http://apachejuddi.blogspot.com/

Microsoft UDDI

DNS for REST Web Service

http://www.infoq.com/articles/rest-discovery-dns

Serviços semelhantes

Ex: WSo2, SAP, etc…

Referências

http://www.w3.org/2002/ws/arch/

http://dx.doi.org/10.1007/s10796-009-9221-9







http://dx.doi.org/10.1007/s10796-009-9221-9

http://dx.doi.org/10.1007/s10796-009-9221-9

http://dx.doi.org/10.1007/s10796-009-9221-9



Criação de sistemas em ambientes distribuídos

Segurança

Projeto de alto risco (se pelo menos dois critérios não sejam cumpridos…)

Aplicação única

Falta de documentação

Equipa de desenvolvimento pouco madura

Sem escalonador automatizado

Requisitos pouco claros

Segurança - Objetivos

Confidencialidade

Integridade

Disponibilidade

Segurança - O que considerar para segurança?

Depende do sistema em questão

Métrica de segurança

Requisitos específicos por sistema

Requisitos de segurança

Ameaças

○ Circunstância ou evento que pode ser prejudicial

Disponibilização, modificação ou destruição de informação

Inviabilização de serviços

Vulnerabilidades

○ Falhas ao nível dos sistemas de controlo

Ameaça + Vulnerabilidade = RISCO!

Qual o impacto de implementação de segurança

Custo?

Performance?

Disponibilidade?

Definição de políticas de segurança

Níveis de acesso

Níveis de permissões

DMZs

Firewall

Cifra de dados



Autenticação forte

Certificados

X.509

Permite

○ Comunicação segura

○ Princípio da não repudiação

○ Mecanismos de accounting mais fidedignos

Segurança

Como evitar…

Man in the middle?

Eavesdropping?

DoS?

…?

Concorrência

Computação em sistemas distribuídos, é por natureza, concorrencial

Como evitar dead locks no acesso aos nossos serviços?

Como evitar questões de acesso concorrente a dados?

Propriedade Intelectual

Necessidade de clarificar e especificar, de forma previamente acordada, sobre quem deverá deter a

prop. intelectual

Gestão conteúdos, administração e auditoria

Que interfaces de gestão terei à minha disposição?

Que tipo de permissões terei sobre a informação?

Como posso controlar quem, como, de onde e quando foram consultados os meus dados?



Acesso a serviços via browser (usando AJAX)

Ajax

Assyncronous Javascript And XML, mas não é acrónimo

Traduzindo por miúdos, chamadas do lado do cliente fora da ordem de chamada de página

Pode usar XmlHttpRequest

Nome pompososo para dizer que é um pedido HTTP que vem formatado em XML

○ Com a entrada em cena de HTML5 há um XMLHttpRequest2

Pode também utilizar jQuery do lado do cliente para auxiliar nas concretização das

funcionalidades pedidas

A informação pode também ser devolvida em JSON

Ciclo de vida de página

Ajax (continuando)

Entretanto, o utilizador aguarda que a página carregue

Mesmo que assim que esta carregar ele selecione outro link

Como resolver esta situação?

Dividindo a página em blocos mais pequenos que podem ser carregados de forma autónoma



Uma espécie de “pequenas” páginas na página grande

○ NAO CONFUNDIR COM IFRAMES

Estes pequenos blocos irão ligar-se ao servidor da mesma forma, mas:

irão consultar menos sistemas

menos bases de dados

menos serviços externos

Logo, cada um deles carregará mais rápido

Assim como na hora de carregar, também na hora de processar pode-se usar Ajax

Significa que APENAS os campos importantes para o pedido são enviados

A página em si não altera

Não há refrescamento (reload)

Não fica menção no histórico da alteração

Alterações invisíveis no código da página

Depois de processada, o bloco alterado pode ser modificado

É também possível forçar uma alteração noutro bloco

Conseguimos desta forma páginas web com uma interatividade mais rica

RIA

Ajax - problemas

A navegação não fica no histórico

Não é linear a gravação nos favoritos

Crawlers, como o google, yahoo, etc não “vêem” a informação que é apenas acessível via Ajax

Sem ovos não há omeletes, e sem javascript, ou com ele desativado, não há Ajax



Ajax - vantagens

Potencia maior interatividade

Aumenta o controlo sobre a quantidade de dados processados pelo servidor em cada instante

Pode levar a um aumento da disponibilidade do servidor

Permite comunicação assíncrona

A página pode interagir com o servidor sem ser por intervenção do utilizador

Do mesmo modo, o utilizador pode interagir com a página sem que esta tenha “carregado”

completamente

Ajax - potencialidades

https://github.com/mui/mochaui

http://mochaui.com/demo

http://layout.jquery-dev.net/demos.cfm

…

https://github.com/mui/mochaui

http://mochaui.com/demo

http://layout.jquery-dev.net/demos.cfm



Escalabilidade

Capacidade do serviço manter a disponibilidade, fiabilidade e performance

à medida que o tráfego simultâneo dirigido ao serviço (a carga) aumenta

Cenário típico de aplicações em produção: são muito bonitas, fazem muita coisa, mas… quando se passa

de um servidor para meia dúzia de pedidos por minuto para um servidor para milhares de pedidos por

minuto, será que a aplicação aguenta?

Performance

Relacionada com a eficiência na resposta a pedidos web

Principais fatores que afetam a performance

Arquitetura da aplicação

Qualidade de construção/implementação

Conectividade a base de dados

Capacidade da rede interna

Capacidade da rede externa

Conectividade a serviços

○ Web services

○ Rss feed

○ Mail

○ …

Recursos de hardware



Performance - Questões fundamentais

Quanto tempo demora responder a um pedido?

Em quanto se degrada a performance com pedidos acrescidos?

Escalabilidade linear

Escalabilidade linear em função de carga

A performance é degradada a um ritmo constante

Escalabilidade linear em função de recursos

A performance melhora a um ritmo constante com a adição de recursos

É meramente teórica. A adição de novos recursos implica lógica adicional para os gerir (exige tempo

e processamento)

Escalabilidade - Efeito de carga

Escalabilidade - Efeito de hardware



Escalabilidade - Arquitetura da aplicação

Aplicações com arquiteturas erradas não escalam

Podem ter bom comportamento para cargas baixas, mas com muita carga, vão abaixo

Escalabilidade - Implementação

“o código não está otimizado”

Até que ponto se deve otimizar o código de algo que ainda não provou o que vale?

Escalabilidade - Base de dados

Acesso a informação

Quando um processo acede a uma linha de informação numa tabela, o que acontece ao

resto da tabela?



Escalabilidade - Capacidade da rede interna

Escalabilidade - Rede interna



Escalabilidade - Vertical vs Horizontal

Escalabilidade Vertical!

“o servidor não é rápido o suficiente”

Upgrade de servidor para um mais rápido

Quanto custa um servidor com o dobro da capacidade?

Escalabilidade Horizontal

“um servidor não chega”

Adquire-se outro para processamento paralelo

Dois não chegam? Juntam-se mais.

Qual o preço de aumentar a capacidade?

Escalabilidade - Implementação e Arquitetura

Implementação

Melhorias permitem escalar a aplicação algumas vezes

Arquitetura

Melhorias permitem escalar muitas mais vezes (várias ordens de grandeza acima)

Modularidade

Diz-se de um sistema ou aplicação se este permitir particionar a sua lógica em componentes mais

pequenas

Cada módulo é independente dos demais

Se uma aplicação é constituída por módulos

Pode-se detetar quais os “botleneck” do sistema e atuar sobre eles

○ Otimizar

○ Escalar os recursos à disposição





Cache

De grande utilidade se houver conteúdos acedidos frequentemente

Pode ser prejudicial se for colocada em cache informação que não é necessária

O ganho de devolver da cache não é superior aos recursos (tempo, processamento, etc)

gastos a guardar e verificar a sua existência)

Breve noção de funcionamento

Cliente pede documento noticias.php

Servidor verifica se existe na cache

Caso exista, verifica a sua validade temporal

Se existir e for válida, devolve a cópia terminada do documento

Caso contrário, gera a página pedida

Acede a todo o sistema de informação e gera a página

Devolve a página ao utilizador e armazena em cache para futuras utilizações

Cache - Níveis

Cache de BD

Resultado de um select é usado por vários pedidos subsequentes

Cache de página

Resultado da geração de uma página é usada por vários pedidos subsequentes

Pode ser ao nível do servidor e do cliente

○ Tudo depende da informação de cache que a acompanha

Cache - do’s & dont’s

Quando usar

Conteúdos esporadicamente alterados

Nº de acessos a páginas específicas superior à média do site por ordem(s) de grandeza

Quando não usar

Conteúdos altamente dinâmicos

Conteúdos altamente específicos de um utilizador



Workers Os trabalhadores incansáveis e as filas de tarefas

Usados para comunicação entre serviços/sistemas

Acesso a base de dados para modificações

Permitem despoletar tarefas agendadas de forma simples

Backups, replicação, atualização de BD, etc.

Podem aliviar a carga das bases de dados

Guardam os pedidos enquanto a BD estiver ocupada com outros pedidos

O que acontece se um worker com tarefas em fila falha/pára/morre?

Pode ter implementados métodos de saber o “andamento” da fila

Via XmlHttpRequest indica ao utilizador que faltam 15 segundos…

Permite aumentar o número de pedidos/sec feitos ao sistema

A resposta mantém-se

Server Farm Quinta de servidores?

Simplificadamente é “um conjunto de servidores logicamente equivalentes com um distribuidor de

carga na entrada”

Distribuidor pode ser hardware ou software

Processo que permite colocar servidores em funcionamento paralelo

Todos os servidores devem suportar as mesmas funções

Cluster?

Sistema redundante

desde que corretamente implementado



Sempre que haja possibilidade de perda de dados ou comunicações, adulteração de informação ou entrega

de informação a terceiros não autorizados, estamos perante riscos de segurança

Tipos de ataque

Eavesdropping

Man in the middle

DoS

SQL Injection

Identity Spoofing

…

Eavesdropping

Alguém está à escuta e, a meio da comunicação, encontram informações que podem ser utilizadas

indevidamente.



Man in the middle



Denial Of Service

Tipicamente levado a cabo pelas chamadas botnets

Traduz-se no consumo de recursos: rede, espaço em disco ou tempo de CPU

SQL Injection

Permite adulterar dados armazenados

Pode, inclusivamente, permitir a destruição de bases de dados

É possível, em certos casos, que o atacante tenha acesso a dados não previstos pelo método

invocado

Identify Spoofing



Serviços seguros

Como endereçar estes problemas?

Depende de vários fatores:

o Nível de controlo de recursos de rede e de controlo de admissão (firewall, etc.)

o Tecnologia usada na nossa aplicação

Pode influenciar a forma de resolução de problemas. Ex.: utilização de SOAP vs. ReST

Comunicação Segura

Certificado Servidor

De um modo geral, sempre que possível, deve-se optar por ter a aplicação sobre HTTPS, com

certificado válido de servidor.

Certificado Cliente

Permite assegurar a identidade do cliente

Não é aplicável em todos os cenários

o Questões de custos

o Processamento



Continuando…

Como vimos, os certificados de servidor são úteis para evitar ataques eavesdropping, man in the

middle e identity spoofing.

E os restantes ataques identificados?

o Carecem de estratégias mais elaboradas e, muitas das vezes, menos standard, visto

dependerem das tecnologias em questão.

Todos menos… SQL Injection!

Quando acontece? Acessos a BD não controlados

SQL Injection

Queries devem ser parametrizadas

o Via stored procedures

o Via chamadas com parâmetros



Finalmente… como garantir a segurança de serviços?

Um serviço implica uma abertura da nossa informação ao mundo

o O que na realidade queremos é a abertura da nossa informação aos utilizadores que devem

ter acesso!

Dependendo do tipo de utilizadores, podem ser pensadas estratégias distintas

Comunicação

Serviço *Serviços

De entre as opções standard, escolher a que melhor se enquadra.

Neste caso, é possível utilizar certificados cliente para autenticação bidirecional

Usando web services SOAP há também a possibilidade de utilizar os cabeçalhos da SOAP para troca

de credenciais

o É necessário que os * serviços consigam comunicar por SOAP

Serviço Browser/Mobile

Em ambos os casos a utilização preferencial será composta por serviços ReST e troca de dados

agregados em JSON

o Não esquecer que o que é pedido na query é público!

No entanto, trata-se de duas utilizações distintas



o No caso do Mobile, tipicamente existirá uma aplicação fechada, que pode incluir chaves

partilhadas

o No caso do Browser, o acesso ao código de invocação dos serviços é linear, pelo que é

necessário ter uma maior reserva sobre o modo de atuar

Serviço Browser (ReST + JSON)

A forma mais comum recorre a um token de autenticação

o Gerado num momento anterior ao pedido

pelo servidor ou por um terceiro, se for um cenário federado

o Passado em todos os métodos como parâmetro

Token pode ainda ser encapsulado num HMAC (Hash-based Message Authentication Code)

o Garante a validade de toda a mensagem

o Útil em cenários sem certificado de servidor

o Pode agregar no HMAC a informação que se entender

Exemplo: user token, timestamp, apikey, parâmetros específicos do método, etc

Serviço Browser (Identificação segura do cliente)

No cenário tradicional, o utilizador autentica-se perante a aplicação para poder aceder à informação

o Deste processo resulta, em regra um Cookie que é enviado para o cliente. Este garante a

validade dos acessos subsequentes.

o No entanto, nem todos os dispositivos estão preparados para cookies…

A garantia da identidade do cliente pode depender dos requisitos do browser

Sugestão:

Método inicial de autenticação do utilizador que devolve um token (com validade temporal)

Do lado do cliente este token é armazenado

Token é enviado com cada nova chamada de métodos

Dica:

Analisar comportamento de soluções de single sign on, como por exemplo oAuth

o Serviços de teste online:

http://term.ie/oauth/example/index.php e

http://term.ie/oauth/example/client.php

o Utilização de oAuth na UA

http://api.web.ua.pt/pt/services/universidade_de_aveiro/oauth

http://term.ie/oauth/example/client.php

Documents

Arquiteturas Distribuídas - Apontamentos TSI · Sistemas de Micro-Kernel - Vantagens Alterações aos módulos em tempo-real Implica o recarregamento do novo módulo Sem necessidade