aula-08

Universidade Presbiteriana Mackenzie

Sistemas Distribuídos

Aula 08 - SOA

(Service Oriented Architecture)

Prof. Rogério Augusto Rondini

Faculdade de Computação e Informática

•

Evolução das arquiteturas

•

Considerações sobre

desenvolvimento tradicional

•

Conceitos fundamentais de SOA

●

Serviços e tipos de serviço,

Composição, ESB

•

Paradigmas de Design de Serviços

•

Estudo de Caso

Introdução a Sistemas Distribuídos 2

Desenvolvimento de Sistemas

●

Desenvolvimento tradicional

● Soluções criadas seguindo o modelo...

– Identificar tarefas a serem automatizadas – Definir requisitos

– Construir lógica correspondente

● Foco em aplicativos específicos

– Controle de estoque – Contas a pagar, etc...

Desenvolvimento de Sistemas

●

Desenvolvimento Tradicional

● Trouxe benefícios ao longo do tempo ● Conjunto limitado de requisitos

● Analistas preocupam-se apenas com o domínio

de um problema específico

● Automação de conjunto específico de processos

de negócio

● Sistemas construídos do zero aproveitam

Desenvolvimento de Sistemas

●

No entanto...

● Pode gerar desperdícios

– Estudos indicam um grande número de funcionalidades redundantes

● Muitas vezes oculta a ineficiência ● Sobrecarrega a empresa

● Necessidade de infraestruturas complexas e

Desenvolvimento de Sistemas

●

Desperdício

● Exemplo → tomando como base o aplicativo

“A”:

– Lógica reduntande 17% e lógica não-redundante

83%

– Escopo do desenvolvimento foi 17% maior do que

o necessário

– Se custo final foi X, a lógica redundante “comeu”

17% 17% Apl. A 18% Apl. B 22% Apl. C

Desenvolvimento de Sistemas

●

Situações comuns

● Diferentes plataformas tecnológicas ● Arquiteturas das mais variadas

● Necessidades específicas de infra-estrutura ● Dificuldades p/ expansão...

Desenvolvimento de Sistemas

42% do orçamento de TI só para fazer “coisa conectar com coisa...”

(GARTNER GROUP) Mais de 70% dos orçamentos de TI são destinados a manutenção de sistemas já existente. (YANKEE GROUP, 03/05) Salve-se quem puder

SOA

●

Estilo arquitetural

●

Paradigma de design

●

Foco em SERVIÇO e não em

APLICATIVO

●

Unidade fundamental da lógica é o

SOA

●

Algumas definições

●

Arquitetura para interoperabilidade de

sistemas por meio de conjunto de serviços

fracamente acoplado... (

)

●

Estilo de arquitetura que promove a

integração entre negócio e TI através de

serviços...(

)

●

… meio para organizar soluções e promover o

reuso (

)

SOA

●

Visão de negócio

●

Arquitetura para agilizar mudanças

●

Redução de custo de desenvolvimento

Integração entre Negócios e TI

●

Visão tecnológica

●

Arquitetura para sistemas distribuídos

Coleção de serviços (service bus)

●

Baixo acoplamento, coesão, reuso e

independência de plataforma

SOA

Algumas expectativas... (nem

sempre concretizadas)

SOA diz respeito a

mudanças nos negócios: Aumenta a velocidade das mudanças, facilita as

conexões de negócios, e melhora o controle dos negócios.

FORRESTER

Motivação para SOA é pelo valor que traz para a área de negócios. Não é uma motivação apenas tecnológica.

YANKEE GROUP Em 2008, 80% dos novos desenvolvimentos de

projetos usarão técnicas de SOA.

SOA

●

Enganos

● Tenho integração de sistemas através de Web

Services, logo, implementei SOA.

● Comprei uma software do fornecedor XPTO que

vai garantir o sucesso da minha implementação de SOA

Serviço

●

Representação lógica de uma atividade

repetitiva (ex: verificar crédito disponível,...)

Alto-contido

●

Pode compor/ser composto por outros serviços

Fracamente acoplado

●

É uma caixa preta sob a ótica do consumidor do

serviço

Serviço

Composição de

serviços

Serviço

●

No caso do exemplo, embora cada

indivíduo preste um serviço

específico, todos precisam ter

algumas características comuns

● Disponibilidade ● Confiabilidade

● Capacidade de comunicação utilizando a

mesma linguagem...

Chave para

Serviço

●

Paradigma de design baseado no

conceito de “separação de

preocupações”

● Um problema maior é efetivamente resolvido

quando decomposto em problemas (preocupações) menores

● Divisão da lógica em capacidades, cada uma

resolvendo uma determinada preocupação

● Possibilidade de Reutilização

● Cada “problema menor” compõe um ou vários

Serviço

Serviços agnósticos quanto aos processos de negócio

A B C D Processos de Negócio Processos de negócio compartilhando serviços

Serviço

A B

A B

Processos de negócio...

como aplicativos independentes (tradicional).

baseado na composição de serviços (SOA).

100% de lógica específica ao processo

Processo B compartilhando lógica com processo A, reduzindo a necessidade de lógica específica

Serviço

●

Em geral, serviços podem ser

classificados de três formas

● Serviços de entidades

– Representa uma entidade de negócio (clientes, funcionários...)

– Altamente reutilizável

Serviço

● Serviços de tarefas

– Serviço que agrupa vários domínios de entidade (consolidação de cobrança...)

● Serviços de utilitários

– Tipicamente serviços de infra-estrutura, orientados pela tecnologia

– Registros de eventos de log, tratamento de exceções...

Serviço

●

Camada de serviços em função de

Paradigmas de design

●

Contrato de serviços padronizados

● Contratos de serviços expressam o propósito e

as capacidades do serviço através de Modelos de dados das entradas e saídas do serviço,

funcionalidades e políticas

● Consumidores de serviços não precisam saber

como o serviço executará a tarefa, mas

precisam saber o que fazem, as pré-condições e o resultado esperado

Paradigmas de design

●

Baixo acoplamento

● Visa reduzir o grau de dependência entre

contratos de serviços, sua implementação e os consumidores.

● Manter interoperabilidade entre serviços e

Paradigmas de design

●

Abstração de Serviços

● Conceito da “caixa preta”

● Ocultar informações que não são necessárias

para o consumo do serviço

●

Capacidade de reuso de Serviço

● Tornar um serviço útil para mais que um único

propósito

● Quanto mais agnóstico for o serviço, ou seja,

quanto maior a independência da plataforma tecnológica e maior a independência da lógica em relação a processo específicos, maior a

Paradigmas de design

●

Autonomia de serviço

● Nível de controle que um serviço tem sobre sua

lógica durante a execução

– Desempenho consistente e aceitável – Confiabilidade

– Previsibilidade

● Independência de sua lógica em relação a

Paradigmas de design

●

Composição de Serviços

● Agrupar capacidades de diferentes fontes para

resolver um problema maior

● Forma de reúso, uma vez que “pequenas

partes” são utilizadas para compor um serviço

Considerações

●

Aumento na complexidade de design

●

Necessidade de padronização

●

Necessidade de mudanças culturais

nas empresas

●

Não é um modelo revolucionário que

irá resolver todos os problemas das

empresas

Inventário SOA

●

Coleção padronizada e governada de serviços

Ativos de TI

●

Servem de base para composição de novos

serviços

●

Pode ser estruturado em camadas, de acordo

com o modelo de serviços (i.e tarefa, entidade,

utilitário)

Contrato de Serviços

●

Foco principal do design de serviços

Propósito do serviço

●

Especificação consistente das capacidades

Tipos de dados de entrada e saída

●

Restriçoes de acesso

Contrato de Serviços

●

Padronização

–

Contrato baseado em WebServices

●

Documentos estruturados

●

WSDL para definição dos serviços

●

XML schemas para definição dos dados

–

Contrato de propósito geral

●

Documento texto não-estruturado

Obs.: Podem existir outras formas de especificação de contratos de serviços (IDL

CORBA por exemplo, dependendo da tecnologia adotada para implementação

Contrato de Serviços

●

Contrato baseado em Web Services

●

Modelo de centralização de esquema

Baixo acoplamento e reúso

Processa Pedido.wsdl Pedido.wsdl Dados Produto.xsd Pedido.xsd

Contrato de Serviços

●

Contrato de propósito geral

●

Sem dependência de tecnologia de

implementação

Serviço Pedidos

Operacao salvar Entrada: documento de pedido

contendo identificador do cliente, lista de itens de pedido e forma de pagamento

Saída: Indicador de pedido gravado

SOA

Passos A considerar

●

Analisar o inventário de serviços

●

Definir serviços de Entidade

● Definir as estruturas de dados necessárias ● Se usar padrão Web Service, utilizar XML

Schema

●

Definir serviços de Tarefa

●

Definição de serviços utilitários

●

Definir a composição de serviços

Contato

Rogério Rondini

rarondini.paradygma@gmail.com