Introdução a Arquitetura Orientada a Serviços

36
http://www.takenami.com.br Introdução a Arquitetura Orientada a Serviços - SOA Igor Takenami Versão 1.0 [email protected] http://twitter.com/itakenami

description

Slides utilizados em sala de aula

Transcript of Introdução a Arquitetura Orientada a Serviços

http://www.takenami.com.br

Introdução a Arquitetura Orientada a Serviços - SOA

Igor Takenami

Versão 1.0

[email protected]://twitter.com/itakenami

http://www.takenami.com.br

O cenário de TI nas Organizações

• Necessidade das organizações em evoluir a gestão de TI = Governança

• Migrar o foco do gerenciamento de dados para o gerenciamento dos processos e clientes

• Redesenho dos processos e implantação dos grandes sistemas de gestão empresarial (ERP)

• Disponibilizar informações corporativas aos usuários ou sistemas que extrapolam as fronteiras das organizações

http://www.takenami.com.br

O cenário de TI nas Organizações• A globalização (início dos anos 90)

- Muitas organizações foram fundidas ou adquiridas

• A diversidade de sistemas coexistindo nas empresas é enorme

- Grandes pacotes comerciais a aplicações desenvolvidas sob-medida

- Diferentes fornecedores de software

- Diferentes tecnologias (monolítica, cliente/servidor, n-tier, etc)

- Diferentes plataformas

http://www.takenami.com.br

Como atender a toda esta demanda ?

http://www.takenami.com.br

Como Integrar ?• Geração de arquivos texto

- FTP como meio

• Banco de Dados

• Requisição

• Os sistemas não estavam preparados para compartilhar seus dados além de suas fronteiras

http://www.takenami.com.br

Como o mercado respondeu• Soluções de integração foram criadas para suprir

as necessidades das empresas

• Outros problemas aconteceram

- falta de escalabilidade

- falta de extensibilidade

- alto acoplamento

- baixa interoperabilidade

http://www.takenami.com.br

Surgimento dos EAI• Apareceram então os EAI (Enterprise Application

Integration) mais conhecidos como Middlewares

• A arquitetura resultante era de fato mais extensível

- Alto custos de aquisição e manutenção

• A aquisição de um middlewares também trazia uma relação de dependência com o fornecedor

http://www.takenami.com.br

Modelo ORB• Object Request Broker

• Funcionalidades de broker com as características da programação O.O.

• CORBA - Common Object Request Broker Architecture

• Linguagem IDL

http://www.takenami.com.br

Tecnologias para Integração• RPC

• CORBA

- Padrão RPC independente de plataforma

• DCOM

- RPC para Windows

• RMI

- RPC para Java

http://www.takenami.com.br

Tecnologias para Integração• Web Services

- Independente de Plataforma

- SOAP

- REST

- Utiliza intra-estrutura existente

http://www.takenami.com.br

Com o amadurecimento e evolução dos componentes distribuídos foi

possível criar uma arquitetura que tem como base os serviços criados por

estes componentes

http://www.takenami.com.br

Service Oriented Architecture - SOA

• SOA é uma arquitetura que representa funcionalidades do software como serviços

• Principais requisitos viram serviços e são acessados por outros serviços

• Modularização e aumento da coesão dos componentes

• Interoperabilidade é muito importante

- Padronização

- Fraco acoplamento

http://www.takenami.com.br

O que é um serviço ?

http://www.takenami.com.br

Características de um Serviço• Independência

• Granularidade

• Visibilidade

• Estado

• Reutilização

• Composição

http://www.takenami.com.br

Independência• Deve fazer sentido isoladamente

- Utilizar tipos de dados básicos

• Interoperabilidade

- Serviços devem estar disponíveis independente de plataforma

http://www.takenami.com.br

Granularidade• Tamanho, escala e nível de detalhe de um serviço

• Granularidade fina (fine-grained)- Muitos “grãos”

- Serviços com poucas operações

- Operações divididas por vários serviços

• Granularidade grossa (coarse-grained)- Poucos “grãos” (maiores)

- Poucos serviços

- Cada um com mais operações

• Serviços robustos são de grossa granularidade e serviços mais leves são de fina granularidade

• Atomicidade

http://www.takenami.com.br

Granularidade• A granularidade de um serviço pode depender da

estratégia de descobrimento do mesmo

- Top-down

- Bottom-up

• A definição de um serviço quanto a sua granularidade dependerá de fatores como capacidade de reúso e performance

• SOA está focado em processos de negócio, por isso sempre que possível opte por top-down

http://www.takenami.com.br

Granularidade• Top-down

- Primeiro identifica os processos de negócios, onde cada atividade dos mesmos podem ser desmembradas em sub-processos e assim por diante, até que não seja mais possível desmembrá-los

- Neste ponto chega-se aos serviços

• Bottom-up

- Os serviços serão expostas através das funcionalidades dos sistemas legados existentes onde a granularidade e atomicidade desses serviços vão sendo refinados, até que os mesmos possam ser compostos (orquestrados) em processos de negócio

http://www.takenami.com.br

Visibilidade• Pesquisa a existência de um serviço

• Repositório de Serviços

- Público

- Pesquisa

- Exploração

• Acesso ao arquivo WSDL

http://www.takenami.com.br

Estado• Um serviço pode ser com estado (stateful) ou sem estado

(stateless)

• Stateless- Não mantém estado entre chamadas, ou seja, todas as variáveis e objetos

envolvidos na execução daquela instância, ao término da execução do serviço, tem seus valores descartados

• Stateful- Mantém estado através das chamadas dos serviços

• Preferencialmente usar stateless- Serviços com estado precisam ser tolerantes a falha

- Serviços com estado trazem overhead de balanceamento de carga

- Complexidade de escalabilidade

http://www.takenami.com.br

Reutilização• Objetivo, mas nunca uma regra

• A identificação dos candidatos a serviço está ligada a reutilização do mesmo

• Um serviço reutilizável não carrega particularidades técnicas, de uma implementação ou regra de negócio específica

http://www.takenami.com.br

Composição• Um serviço pode se compor com outro serviço

com a finalidade de expor um novo serviço

• A forma como esses serviços serão compostos é chamada de orquestração

- Toda composição deve resolver um problema de negócio

http://www.takenami.com.br

Características de SOA• Ponto de vista: Técnico X Negócio

• Orientada a Serviço

- Expressam uma metodologia para desenvolvimento de software

• Arquitetura

- Panorama de todos os ativos de software de uma empresa

- Planta arquitetônica que representa todas as peças que, juntas, formam uma construção

http://www.takenami.com.br

Características de SOA• É um estilo de projeto, com vários aspectos

- Arquitetural, metodológico e organizacional

- Portifólio de serviço

• A metodologia de desenvolvimento em si não traz vantagens

- O efeito que ela tem sobre uma infra-estrutura redundante e complexa que o faz

• Um bom aplicativo orientado a serviços envolve mais trabalho do que a tradicional integração de software

• Pesquisas mostram que SOA está sendo usada para integração tradicional de aplicativos na maioria das empresas

http://www.takenami.com.br

Vantagens de SOA• Desenvolvimento Orientado a Serviço

- Reutilização de Software

- Aumento de produtividade

- Maior Agilidade

• Estratégia SOA

- Melhor alinhamento com o negócio

- Maneira melhor de vender arquitetura para o negócio

http://www.takenami.com.br

Integração Ponto-a-Ponto

http://www.takenami.com.br

Integração Centralizada

http://www.takenami.com.br

Barramento de Serviço

http://www.takenami.com.br

Conectores

http://www.takenami.com.br

Enterprise Service Bus• Não implementa uma arquitetura orientada a serviço

- Fornece as características para que possa ser implementado

• A maioria dos fornecedores constroem ESB’s para incorporar princípios de SOA

- Business Process Execution Language (BPEL)

• Integrações espaguetes produzidas ao longo dos anos, não some com a implantação de um ESB

- Ficam escondida sob uma camada de tecnologia

http://www.takenami.com.br

Vantagens de um ESB• Redução de Conexões Ponto-a-Ponto

• Funciona como um Middleware para integração de aplicações que seguem uma especificação definida

• Fornecem uma base de serviços para arquiteturas mais complexas

• Utiliza padrões baseados em mensagens

http://www.takenami.com.br

Características de um ESB• Transformação de dados

• Roteamento

• Gerenciamento

• Monitoramento

• Logging

• Integração

http://www.takenami.com.br

Mashups• Aplicação que combina elementos e conteúdos de

outras ferramentas, formando uma nova

• É a combinação de várias funcionalidades e recursos de diferentes fontes, reunidos em um só lugar, com por exemplo em um site

• Na formação dessa aplicação "híbrida" inclui-se o uso de API’s externas (Serviços)

• Um exemplo é o uso do Google Maps em sites que precisam de localização para prover outro serviço

http://www.takenami.com.br

Cloud Computing• Utilizar capacidades de armazenamento e

processamento de computadores e servidores compartilhados e interligados por meio da Internet

• Segue o princípio de grid computacional

• O armazenamento de dados é feito em servidores que poderão ser acessados de qualquer lugar

• Não é necessário instalação de programas, serviços ou de armazenar dados

• O acesso a programas, serviços e arquivos é remoto, através da Internet

http://www.takenami.com.br

Cloud Computing

http://www.takenami.com.br

Dúvidas ?