to soa or not to soa

Uma apresentação buzzword compliant

Hugo José Pinto hugo.pinto@gmail.com

•  Hugo José Pinto –  Principal responsável da KnowledgeWorks (consultora especialista em Java e SOA)

–  Profissional Java desde 1996 –  Core Member do PT JUG –  http://www.twitter.com/hugojpinto

–  Techie assumido e entusiasta de all things Java …e não só: mobilidade, iPhone & Android, etc.

2

•  A empresa onde trabalho implementou recentemente uma arquitectura SOA complexa –  num cliente de Administração Pública –  com múltiplos fornecedores envolvidos –  complexidade razoável

…e passámos tempos muito interessantes de dolorosa e salutar aprendizagem

•  Quisemos partilhar este conhecimento convosco

3

•  Arquitecturas Orientadas a Serviços (SOA) são uma estratégia em TI que promove organização das funcionalidades presentes em múltiplas aplicações de negócio em serviços inter-operáveis e baseados em standards, que podem ser recombinados e reutilizados de forma fácil para se adaptarem a novas necessidades de negócio!

4

•  Arquitecturas Orientadas a Serviços (SOA) são: –  uma estratégia em TI –  promove organização das funcionalidades presentes em

múltiplas aplicações de negócio em: •  serviços inter-operáveis •  baseados em standards

–  que podem: •  ser recombinados •  Ser reutilizados

–  de forma fácil para se adaptarem a novas necessidades de negócio!

5

Sistema 1

6

Web App

Lógica Negócio

Acesso Dados

Dados de Negócio

Sistema 2

Web App

Lógica Negócio

Acesso Dados

7

Web App

Lógica Negócio

Acesso Dados

Dados de Negócio

Web App

Lógica Negócio

Acesso Dados

•  Maior reutilização –  Serviços são “blocos” prontos a usar

•  Melhor Interoperabilidade

•  Mais flexibilidade –  Serviços assíncronos –  Facilidade de recombinação (BPM)

•  Mais eficiente em custo –  Baseado em standards vs. integrações específicas

8

9

10

11

•  Muitos web services juntos não fazem uma arquitectura SOA… –  …apenas uma grande confusão

•  SOA é, em teoria, “compatível” com aproximações menos canónicas de serviços web –  Nomeadamente, serviços RESTful

•  Uma arquitectura SOA requer uma infra-estrutura de suporte ao ciclo de vida dos seus serviços

12

13

14

15

•  WARNING: Assunto subjectivo! :)

•  Consideramos as peças mínimas em SOA: –  Um Bus unificado de Serviços –  Um Service Registry –  Uma suite de BPM –  (opcionalmente) um Portal unificado

•  Depois, podemos ainda ter: –  Serviços de Dados –  Serviços de Apresentação

16

•  O Bus é um router de mensagens, idealmente transparente para quem o utiliza

•  Esta peça é a chave para garantir que os serviços têm baixo acoplamento e que a arquitectura é resistente à mudança

•  O Bus intercepta todas as mensagens num ecossistema SOA, e DECIDE qual o seu destino

17

18

•  O ESB só não faz sentido para projectos MUITO pequenos, e em que o ciclo de vida do sistem aé muito controlado e limitado

•  O Bus é a pedra basilar das versatilidade e fiabilidade das arquitecturas SOA

•  Se tiverem evolução de serviços em continuidade de negócio, INCLUAM um ESB

19

20

21

•  O Service Registry (muitas vezes, também Repository) guarda páginas amarelas sempre fidedignas dos serviços existentes

•  Pode ser usado para a descoberta inicial de serviços, ou pode ser usado implicitamente pelo Bus

•  Quando novas versões de um serviço são disponibilizadas, o registry regista essa nova versão, e o Bus decide como enviar os pedidos

22

23

•  No inicio, o Registry parece opcional – temos apenas uma release de todos os serviços, e temos apenas um conjunto limitado de clientes

•  Com o escalar da complexidade, abre-se a caixa de pandora – e começa o esparguete

•  Num projecto complexo, o Registry é tão essencial como o Bus

24

•  Um motor de BPM acrescenta a uma arquitectura SOA a capacidade de alterar a orquestração dos seus componentes de lógica de negócio, idealmente sem reprogramação dos mesmos

•  “Nice” :) – em principio, sim… –  Mas aumenta também a complexidade –  Introduz preocupações de performance –  Introduz um novo paradigma de desenvolvimento

25

26

•  Um processo BPM passa a ser um Serviço –  Um Web Service – reutilizável, versionável, etc.

•  Duas versões do mesmo processo podem estar a executar, teoricamente, ao mesmo tempo

•  Existe o apelativo POTENCIAL de passar estas mesmas ferramentas para a mão de não-técnicos –  BIG DANGER here – há implicações!

27

•  As suites de BPM são úteis em projectos complexos, em que faz sentido que a lógica de orquestração das peças do negócio mude “frequentemente” –  E em que o custo de alteração do sistema seja alto –  Em que não haja acesso ao código dos serviços –  Em que existam multiplos fornecedores envolvidos

•  As suites de BPM não servem para algoritmia aritmética – servem para orquestração alto-nivel!

•  Managers shoudn’t do it – they don’t want to!

28

•  Portal Unificado

•  Serviços de Apresentação

•  Serviços de Dados

29

30

31

hugo.pinto@gmail.com hugojpinto on twitter

http://www.hugojpinto.com