Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

To SOA or not to SOA

778 views

Published on

Apresentação de Hugo Pinto - JavaPT09.

Published in: Technology
  • Be the first to comment

  • Be the first to like this

To SOA or not to SOA

  1. 1. Uma apresentação buzzword compliant Hugo José Pinto hugo.pinto@gmail.com
  2. 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. 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. 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. 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. 6. Sistema 1 Sistema 2 Web Web App App Lógica LógicaNegócio Negócio Acesso Acesso Dados Dados Dados de Negócio 6
  7. 7. Web Web App App Lógica LógicaNegócio NegócioAcesso AcessoDados Dados Dados de Negócio 7
  8. 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. 9
  10. 10. 10
  11. 11. 11
  12. 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. 13
  14. 14. 14
  15. 15. 15
  16. 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. 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. 18
  19. 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. 20
  21. 21. 21
  22. 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. 23
  24. 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. 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. 26
  27. 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. 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. 29. •  Portal Unificado•  Serviços de Apresentação•  Serviços de Dados 29
  30. 30. 30
  31. 31. 31
  32. 32. hugo.pinto@gmail.com hugojpinto on twitterhttp://www.hugojpinto.com

×