to soa or not to soa
DESCRIPTION
Apresentação de Hugo Pinto - JavaPT09.TRANSCRIPT
• 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
