To SOA or not to SOA
Upcoming SlideShare
Loading in...5
×
 

To SOA or not to SOA

on

  • 575 views

Apresentação de Hugo Pinto - JavaPT09.

Apresentação de Hugo Pinto - JavaPT09.

Statistics

Views

Total Views
575
Views on SlideShare
408
Embed Views
167

Actions

Likes
0
Downloads
3
Comments
0

3 Embeds 167

http://jug.pt 142
http://ptjug.wordpress.com 17
http://lanyrd.com 8

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

CC Attribution-NonCommercial-NoDerivs LicenseCC Attribution-NonCommercial-NoDerivs LicenseCC Attribution-NonCommercial-NoDerivs License

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

To SOA or not to SOA To SOA or not to SOA Presentation Transcript

  • 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 Sistema 2 Web Web App App Lógica LógicaNegócio Negócio Acesso Acesso Dados Dados Dados de Negócio 6
  • Web Web App App Lógica LógicaNegócio NegócioAcesso AcessoDados Dados Dados de Negócio 7
  • •  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 twitterhttp://www.hugojpinto.com