A apresentação discute arquiteturas orientadas a serviços (SOA) e seus principais componentes. SOA promove a organização de funcionalidades de negócio em serviços interoperáveis e baseados em padrões que podem ser recombinados e reutilizados facilmente. Os componentes essenciais de uma arquitetura SOA incluem um barramento de serviços unificado, um registro de serviços e uma suíte de gestão de processos de negócios.

1. Uma apresentação buzzword compliant
Hugo José Pinto
hugo.pinto@gmail.com

2. • 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

3. • 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

4. • 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

5. • 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

6. Sistema 1 Sistema 2
Web Web
App App
Lógica Lógica
Negócio Negócio
Acesso Acesso
Dados Dados
Dados de Negócio
6

7. Web Web
App App
Lógica Lógica
Negócio Negócio
Acesso Acesso
Dados Dados
Dados de Negócio
7

8. • 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. 9

10. 10

11. 11

12. • 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. 13

14. 14

15. 15

16. • 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

17. • 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. 18

19. • 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. 20

21. 21

22. • 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. 23

24. • 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

25. • 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. 26

27. • 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

28. • 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

29. • Portal Unificado
• Serviços de Apresentação
• Serviços de Dados
29

30. 30

31. 31

32. hugo.pinto@gmail.com
hugojpinto on twitter
http://www.hugojpinto.com