Prof.

Mário Melo
mario.melo@ifrn.edu.br
"Uma abordagem arquitetural de TI centrada no
negócio que suporta a integração de sua empresa
através de tarefas comerciais ou serviços vinculados,
repetíveis."
-IBM
"A service-oriented architecture is essentially a
collection of services. These services communicate
with each other. Some means of connecting services
to each other is needed."
-service-architecture.com

Prof. Mário Melo 2

 Ponto vista do negócio
‣ É a mais recente iniciativa para desenvolver soluções de
tratamento da informação aderente aos negócios;
‣ É uma abordagem que visa aumentar a eficiência do capital
estrutural;
‣ É um estratégia para aumentar o valor percebido pelos
clientes;
‣ É uma arquitetura para agilizar as mudanças nos negócios.
 Ponto de vista tecnológico
‣ É uma coleção de serviços (barramento de serviços);
‣ Utiliza topologia de rede para realizar a troca de mensagens;
‣ Garante serviços fracamente acoplados, altamente coesos e
com alta possibilidade de reutilização.

Prof. Mário Melo 3

 Objetivos
‣ Maior Interoperabilidade Intrínseca
‣ Maior Federação
‣ Alinhamento entre a T.I. e o negócio
‣ Independência de fornecedores
 Benefícios
‣ Maior retorno sobre investimento (ROI)
‣ Maior agilidade organizacional
‣ Redução da carga de trabalho da TI

Se os objetivos são
alcançados, obtêm-
se os benefícios.

Prof. Mário Melo 4

 .... o acrônimo de Arquitetura Orientada a Serviços.
‣ Em inglês, Service-Oriented Architecture.

 Certo..... mas o que é uma Arquitetura?

Prof. Mário Melo 5

Essa?

Estamos falando de arquitetura de software!

Prof. Mário Melo 6
“Arquitetura de software de um sistema é o conjunto
de estruturas necessárias para raciocinar sobre o
sistema, que inclui elementos de software, relações
entre eles e propriedades de ambos”
-SEI
"Arquitetura de software é a organização fundamental
de um sistema que compreende os componentes,
suas relações uns com os outros e com o ambiente,
além de princípios de regem sua evolução e design"
- IEEE

Prof. Mário Melo 7

Prof. Mário Melo 8
Prof. Mário Melo 9
Prof. Mário Melo 10
 Serviço
‣ É um pacote de funcionalidades padronizadas tipicamente
relacionados.
‣ São elementos de software:
‣ Independentes;
‣ Características próprias;
‣ Operações distintas;
‣ Características:
‣ Fracamente Acoplado;
‣ Independente de plataforma;
‣ Interface bem definida;
‣ Foco na reusabilidade.

Prof. Mário Melo 11

 Características para descrever completamente um
serviço:
‣ Service requester (“client”)
‣ Quem necessita/irá usar o serviço
‣ Service provider (“server”)
‣ Quem prover/implementa o serviço
‣ Qualities of Service (QoS)
‣ Que parâmetros descrevem um bom de um mal serviço?
‣ Ex.: Confiabilidade, tempo de execução, corretude, segurança,
etc.

Prof. Mário Melo 12

 Serviço de Entidade
‣ É totalmente centrado no negócio.
‣ É altamente reusável.
‣ Agnóstico.

Prof. Mário Melo 13

 Serviço-tarefa
‣ Diretamente ligado a uma tarefa ou processo do negócio.
‣ Tem menos potencial de reuso.
‣ Processo específico de uma organização específica.
‣ Normalmente é o controlador de uma composição de
diversos serviços.

Prof. Mário Melo 14

 Serviço utilitário
‣ É dedicado a fornecer funcionalidades reusáveis.
‣ É possível compor diferentes aplicações.
‣ Não está diretamente ligado ao negócio.
‣ Ex.:
‣ Serviço de log
‣ Tratamentos de Erros

Prof. Mário Melo 15

Prof. Mário Melo 16
 Para ser definido como um estilo de arquitetura de
aplicações orientado a serviços é necessário atender os
seguintes critérios:
‣ Não ser monolítico;
‣ Os principais blocos de funcionalidades devem ser providos
através de serviços.
‣ Assim, a utilização das funcionalidades independerá de
implementação.
‣ Possuir os seguintes elementos de design:
‣ Componentes: serviços (podendo ser combinados), provedores e
consumidores.
‣ Conectores: invocação do serviço (remoto).
‣ Regras de configuração:
‣ Sem camadas definidas
‣ Sem entidade centralizadora
‣ Os serviços devem ser projetados para serem compartilhados.
Prof. Mário Melo 17
 É um princípio organizacional....
‣ É um conjunto de princípios para construir grandes
sistemas;
‣ Não está atribuído a nenhuma tecnologia.
‣ Exemplo:
‣ Serviços horizontais:
‣ Comum a diversos negócios/aplicações;
‣ Logs, autenticação/SSO (single-sign-on), gerenciamento de
sistemas.
‣ Serviços verticais:
‣ Específico para um domínio de negócio;
‣ Serviço de busca de produto, Status de pedido, etc.

Prof. Mário Melo 18

 ... seguir 4 princípios:
1. Limites devem ser explicítos
‣ Serviços devem se comunicar através da troca de
mensagens;
‣ Cada troca de mensagens atravessa limites e pode ter
custos.
2. Compartilhar esquema e contratos ao invés de tipos
‣ Serviços expõem esquemas, definindo:
‣ Estruturas de dados;
‣ Contratos definam as operações.
‣ Contratos e esquemas podem evoluir separadamente.

Prof. Mário Melo 19

 ... seguir 4 princípios:
3. Definir uma política de serviço
‣ Define os requisitos de comunicação necessário para
interação do serviço.
4. Serviços são autonômos
‣ Não devem armazenar estados;
‣ Devem ser capazes de se recuperar de falhas.

Prof. Mário Melo 20

.... SOA é qualquer arquitetura que conseguir
abarcar os quatro princípios da orientação a
serviço.

Prof. Mário Melo 21

 Expectativa Realidade
• Uma tecnologia ou um • É um paradigma
conjuntos de tecnologias; arquitetural para
• É revolucionário; construção de sistemas
• É o objetivo final; distribuídos;
• Requer a revisão do • É evolucionário;
negócio e as tecnologias • É o meio para um fim;
utilizadas; • Pode e deve ser
• É complexo e requer um evolucionário;
batalhão de consultores. • É simples.

Prof. Mário Melo 22

 Expectativa Realidade
• Uma tecnologia ou um • É um paradigma
"The onlydeway
conjuntos you can use SOA
tecnologias; for everything
arquitetura para is
•Étorevolucionário;
rename everything to SOA" construção de sistemas
• É o objetivo final;
- Roydistribuídos;
Schulte, Gartner
• Requer a revisão do • É evolucionário;
negócio e as tecnologias • É o meio para um fim;
utilizadas; • Pode e deve ser
• É complexo e requer um evolucionário;
batalhão de consultores. • É simples.

Prof. Mário Melo 23

Prof. Mário Melo 24
Transição

Prof. Mário Melo 25

 Contrato de serviço padronizado;
 Baixo Acoplamento.
 Capacidade de reuso;
 Independência de estado (Stateless);
 Composição;
 Autonomia do serviço;
 Abstração de serviço;
 Visibilidade do Serviço (Discoverability);

Prof. Mário Melo 26

 Contrato de serviço padronizado
‣ Forma em que o serviço expressa a funcionalidade;
‣ Reduz a necessidade de transformação de dados pois
utiliza modelos consistentes;
‣ Facilita o entendimento;
‣ Facilita a interoperabilidade;
‣ Contratos são a base arquitetural do SOA
‣ Técnicos;
‣ Não-Técnicos.

Prof. Mário Melo 27

 Baixo Acoplamento
‣ Em TI, acoplamento = dependência;
‣ Acoplamento = Relacionamento entre 2 coisas;
‣ Os serviços devem ser minimamente (não) dependentes
‣ De implementação;
‣ De relação entre serviços;
‣ Evita relacionamentos restritivos;
‣ Aumenta o poder de reuso;
‣ Mudanças geram menos impacto.

Prof. Mário Melo 28

 Abstração do Serviço
‣ Expor apenas as informações necessárias para os
consumidores;
‣ Reduz o impacto de possíveis mudanças.
‣ Esconder detalhes internos;
‣ Quanto menos informação, mais desacoplado;
‣ Esconder tecnologia;
‣ Esconder lógica.

Prof. Mário Melo 29

 Capacidade de Reuso
‣ Os serviços devem ser reusáveis;
‣ Preferencialmente devem ser agnósticos;
‣ Evitar a repetição de lógicas de negócio;
‣ Maximizar o ROI.

Prof. Mário Melo 30

 Autonomia
‣ Devem possuir a capacidade de se autogovernar.
‣ Independência da lógica de execução.
‣ Aumento da confiabilidade, desempenho e previsibilidade.
‣ Principalmente ao ser usado ou composto em outros
serviços.

Prof. Mário Melo 31

 Independência de Estado
‣ Stateless, Sem estado
‣ Devem ser projetados para depender o mínimo de
informações de estado.
‣ A natureza do serviço é temporária.
‣ Deve-se evitar alocação de recursos por longos períodos.
‣ Melhora a escalabilidade e o suporte a lógica agnóstica.

Prof. Mário Melo 32

 Visibilidade de serviço
‣ Priorizar sempre a utilização de serviços existentes.
‣ Devem ser projetados para serem descobertos e
interpretados.
‣ Utilizar meta-informações para categorizar e descrever os
serviços.
‣ Evita a criação de lógicas redundantes.

Prof. Mário Melo 33

 Composição de serviço
‣ Os serviços devem ser projetados para atuarem como
participantes de composições.
‣ Pode-se unir diferentes serviços afim de prover uma nova
funcionalidade ligada ao negócio.
‣ Riscos associados:
‣ Ponto único de falha.
‣ Desempenho.
‣ Complexidade.

Prof. Mário Melo 34

 Composição de serviço
‣ Formas de composição
‣ Orquestração
‣ Controle centralizador
‣ Papéis
‣ Controlador (Serviço-tarefa)
‣ Membros.
‣ Pertencem a uma única organização.

Prof. Mário Melo 35

 Composição de serviço
‣ Formas de composição
‣ Coreografia
‣ Lógica de negócio distribuída
‣ Não há controlador, todos colaboram
‣ Inter-organizações
‣ Business-to-Business (B2B)

Prof. Mário Melo 36

Prof. Mário Melo 37
Prof. Mário Melo 38
 Conjunto de Web Services oferecendo acesso a
código existente.
 Solucão para qualquer tipo de problema.
‣ Tem que avaliar questões de negócio, benefícios, etc.

 EAI - Integração de aplicações corporativas.

Prof. Mário Melo 39

Prof. Mário Melo 40
Prof. Mário Melo 41
ERL, Thomas. Service-oriented architecture: concepts,
technology, and design. Pearson Education India, 2005.

BASS, Len. Software architecture in practice. Pearson

Education India, 2012.

Microsoft. Service Oriented Architecture: Right on Track.

Microsoft, 2005. Acessado em 02/04/2018

Prof. Mário Melo 42