2. Benefícios de SOA
• TI flexível e ágil.
─ “Time-to-Market” mais rápido.
• Processos de negócio passíveis de alteração.
• Simplificação da integração de negócios com clientes
e parceiros
• Redução de custos para desenvolvimento ou
evolução de aplicações.
• Maximização do uso do legado tecnológico
existente.
2
3. Quando Implementar SOA
• Ambiente com diversidade de legados que não se
comunicam.
• Necessidade de diminuir dependência de
fornecedores de softwares específicos.
• Criação de processos de negócios flexíveis.
• B2B.
• Fusões e aquisições.
• Expansão de negócio.
3
4. Quando Não Implementar SOA
• Ambiente de TI homogêneo e padronizado.
• Performance “real-time” é crítica.
• Processamentos não são alterados (visibilidade
de alteração é pequena).
• Alto nível de acoplamento é bom
─ Por exemplo: sistemas pequenos com
componentes que residem no mesmo
equipamento.
Referência: Jason Bloomberg, “When Not To Use an SOA”,
http://www.zapthink.com/report.html?id=ZAPFLASH-02162004
4
5. Arquitetura: Definição
• Uma arquitetura é um conjunto de componentes
tecnológicos (HW e SW) em um determinado
contexto para atingir objetivos bem definidos.
• Uma arquitetura é um processo vivo, não um
documento estático.
• Deve evoluir em resposta às mudanças dos
objetivos de uma organização e às tecnologias
disponíveis.
5
6. Fato #1: SOA = Arquitetura
• SO “Architecture”. SOA é uma arquitetura de serviços
de negócio.
• “Service” OA. O que importa é a definição de serviços
pertinentes ao negócio, a uma indústria e de uma
empresa em particular. O “S” significa “Serviço de
Negócio”.
• SOA não pretende resolver questões tecnológicas de
baixo nível: controle de acesso a arquivos,
processamento transacional etc.
• SOA ≠ Produtos
• SOA ≠ Middleware
• SOA ≠ Software
• SOA ≠ Enterprise Service Bus
• SOA ≠ Web Services
• SOA ≠ ...
6
7. SOA - Finanças
Camada de
Apresentação e
Acesso
Camada de
Processo
Cartão de Aplicações
Crédito Financeiras
Camada de
Serviço
Detecção de Cálculo de
Análise de Fraude Serviços de Juros Extratos
Serviços de
Crédito Acesso Dados
Camada de Recurso e
Dados (legado)
Dados de CRM ERP Dados de
Créditos Clientes
7
8. SOA - Telecomunicações
Camada de
Apresentação e
Acesso
Camada de
Processo
VoIP Acesso
xDSL
Camada de
Serviço
Billing Venda de Ativação de
Detecção de Produtos Fullfilment Serviços Aprovisionamento
Fraude
Camada de Recurso e
Dados (legado)
Dados de CRM ERP Dados de
Parceiros Clientes
8
9. Hierarquia de Serviços
Processo de Negócio
Corporativo
Serviço de Negócio Serviço de Negócio
...
Domínio de Serviços
... Domínio de Serviços
Serviço Utilitário
Serviço de Integração Serviço Externo
...
Referência: Michael Rosen,
“Service-Oriented Architecture – Basic Integration”
http://www.omg.org/news/meetings/workshops/MDA-SOA-WS_Manual/01-A1_Rosen.pdf
9
10. Fato #2: SOA Não é Novo
• SOA é o conjunto de todas as melhores práticas
para o desenvolvimento de aplicações
acumuladas nos últimos 40 anos.
• Por exemplo, conceitos aplicados em SOA, como
Acoplamento e Coesão, foram formalizados em
1979 por Larry Constantine e Edward Yourdon
no livro “Structured Design: Fundamentals of a
Discipline of Computer Program and Systems
Design.”
10
11. Fato #3: SOA Deve Alinhar Tecnologia e Áreas de Negócio
11
12. Requerimentos de um Serviço
• Um serviço responde por requisições através de
interfaces bem definidas, padronizadas e
publicadas. Interface
• É um componente auto-contido que implementa
do Serviço
funcionalidades de negócio com um conjunto
Consumidor
extenso Qualidades não funcionais
do Serviço de aspectos
Não-Funcionais Lógica de Negócio
Funcional
12
13. Aspectos Não-Funcionais
• Versionamento
─ Funcional e formatos
• “Throughput”
─ Garantir o número de mensagens processadas
em um período de tempo
• Tempo de vida do serviço
• Bilhetagem de uso do serviço
• Monitoração
─ Métricas
─ Relatório e ferramentas de alerta
─ Incorporação de ferramentas existentes
• Segurança
─ Autenticação e autorização
• Tempo de recuperação em caso de falha
• “Compliance”
─ Regulamentações governamentais
13
14. Fato #4: SOA Necessita de Processos Formais e Específicos
B S 's
B S 's
B S 's
B S 's
B S 's
B U S IN E S S BBSS 's
B u s in e s s DAB specs
TEST
r e q 's SO A TEST
T E sS esT se c s
p
(D a t a c e n t e r T E sSe Ts
p c
fo r th e In p u t A rc h it e c t u re TEST
p c
t u T E sSse Tes c s
p
In p
(A rc hBitlu c tpurin t )
e e re p c
T E sS eT s
s e r v ic e B lu e p rin t )
p c
specs
IT o r g a n is a tio n 's s tr a te g ic
a r c h ite c tu r a l c h o ic e s a n d
S D P P ro c e s s s ta n d a r d s ...
A lw a y s a g a p b e tw e e n b u s in e s s a n d Ou O ut
put
GAP tp u
O ut
IT w ith r e s p e c t to s e r v ic e c o s t,
q u a lity , r e q u ir e m e n ts e tc . t
put
ut
In p
IT -, o p s - & SLA / OLA C o s ts o f A r c h it e c t u r e
UCs im p le m e n ta tio n
app- & and m gm t (A d e f in e d
d e v e lo p m e n t - im p le m e n t a t io n
(S e rv ic e L e v e l- & a rc h it e c t u re
s id e 's O p e ra t io n a l L v l (H W , S W , lic e n s e / d e s ig n )
r e q 's t o A g re e m e n t s & n e e d s , p ro je c t ,
U n d e rp in n in g s t a f f in g , e x t e rn a l,
s e r v ic e IT / T E C H N IC A L C o n t ra c t s ) in t e rn a l . . . . e t c ! )
C r e a te a n “ a lig n m e n t” b e tw e e n th e c o s ts fo r o p e r a tin g a n d im p le m e n tin g th e
s e r v ic e ( s ) A N D th o s e c o n tr a c ts th a t s h o u ld b e p u t in p la c e
14
15. Arquiteto de Aplicações
• Responsável pela definição da arquitetura de
uma aplicação ou sistema.
• Conhecimentos esperados: tecnologias Java e
JEE, “frameworks”, Software Design Patterns, etc.
• Normalmente suas preocupações são de ordem
funcional.
Bancos de
Dados
Lógica Lógica Lógica
de de de
Apres. Negócio Integração
Legado
Servidor de aplicação
15
16. Fato #5: SOA Traz um Novo Perfil de Arquiteto
• Arquiteto Corporativo
─ Normalmente não é o responsável pela
arquitetura de uma aplicação.
• Responsabilidades
─ Arquitetura envolvendo os componentes do
ecossistema tecnológico de uma corporação:
Servidores de Aplicações, Servidores Web, LDAP,
Portal, ESB, Mainframes, Brokers, Monitores de
Transação, Autenticação e Autorização, CRM, ERP,
etc, etc, etc.
─ Implementação de aspectos não funcionais: alta
disponibilidade, escalabilidade, performance,
segurança etc, etc, etc.
─ Interação com analistas de negócio para
entendimento de requerimentos funcionais e
níveis de serviço.
─ Enterprise Application Patterns, Middleware
Platform Patterns, Application Integration Patterns
16
17. Pequeno Exemplo de Arquitetura Corporativa
Camada de Acesso
Balanc. Balanc.
Firewall Firewall
de Carga de Carga
Serv. Serv.
Portal Portal
Web Web
Camada de Serviços e Processos de Negócio
BAM
Model. BPM
de Proc.
Neg.
Reg. E
ESB Rep. Serv.
Camada de Lógica de App Camada de Identidade
Autent.
Aprovis. Emissor
Mainframe ERP CRM Autor.
Usuarios Cert. Dig.
Usuarios
Cluster de AppSrv's Ecossistemas próprios
Camada de Dados
LDAP RDBMS Cluster RDBMS LDAP MS-AD Radius Kerberos
Discos
17
18. Arquiteto Corporativo
Analistas de Arquiteto de
Negócio Aplicações
Situação Atual
Analistas de Arquiteto de
Negócio Aplicações
Arquiteto
Corporativo
Projeto SOA
18
19. Mito #1: SOA = Integração de Sistemas
• Integração de Sistemas
─ Resolve problemas de integração de nível de
abstração baixo.
─ Não necessariamente define uma nova
camada de abstração com serviços de
negócio.
• SOA
─ Tem como principal objetivo a definição de
uma camada de abstração com serviços de
negócio.
─ Faz uso da infra-estrutura de integração.
• Projetos de SOA devem ser conduzidos de forma
diferente da aplicada em projetos de integração.
19
20. Mito #2: SOA = Web Services
• Web Services
─ Serviços e lógica de negócio são expostos de
forma fracamente acoplada (“loosely
coupled”) .
─ Usa protocolos de baixo nível.
• SOA
─ A partir dos serviços de negócio, habilita nível
de funcionalidade mais alto como processos
de negócio, gerenciamento de serviços,
identidade, etc.
• Web Services, tipicamente, são a primeira opção
tecnológica para a implementação de SOA.
• Por outro lado, SOA pode ser implementada com
outras tecnologias:
─ CORBA, RMI, DCOM, DCE, sockets, REST, etc.
20
21. Modelo de Implementação de Serviços
• Um dos modelos largamente usados para a
implementação da camada de serviços é aquela
baseado no paradigma “find-bind-execute”.
─ Provedores registram seus serviços em um repositório público.
─ Consumidores procuram no repositório serviços que satisfaçam seus
requerimentos.
─ Os repositórios fornecem aos consumidores o “contrato” para o uso do
serviço.
─ Consumidores usam o “contrato” para interagir com o provedor.
• Isso não é particular a Web Services. O que acontece é
que os Web Services também seguem este paradigma.
21
22. Mito #3: SOA = “Webficação” de Legado
• “Webficação”
─ “Casca” Web para acesso a aplicações existentes.
• SOA
─ É mais voltado a “wrap and reuse” (“webficação”)
do que a “rip and replace”.
─ Entretanto, a relação entre um serviço e os
legados pode não ser 1:1.
─ Além disso, para a implementação da camada de
serviços, SOA deve considerar os aspectos não
funcionais destes serviços: escalabilidade,
performance, alta disponilidade, etc.
─ “Webficação” pode ser uma das primeiras fases do
processo de adoção de SOA (aproximação
“bottom-up”)
22
23. Mito #4: SOA = Serviços + BPM
• A camada de serviços de negócio deve ser implementada para
ser consumida por quaisquer outras tecnologias.
• O BPM (“Business Process Management”) é, talvez, o primeiro
consumidor dos serviços, mas não o único.
• O BPM realiza a composição de serviços. A orquestração destes
serviços se dá através de “workflow”.
• Os projetos da camada de serviços (SOA) e processos de negócio
(BPM) deveriam ser conduzidos distintamente:
─ Requerimentos diferentes
─ Agendas diferentes
─ Modelagem, desenho, monitoração, implementação,
execução diferentes.
─ Tecnologias e produtos (eventualmente) diferentes
─ Equipes de implementação (eventualmente) diferentes
─ Usuários finais diferentes
23
26. Mito #5: Projetos de SOA Resolvem Problemas de Legado
• A Arquitetura de Serviços define um nível de
abstração novo.
• O novo nível presume que os sistemas e
aplicações usados atendem os seus
requerimentos funcionais e não funcionais.
─ Por exemplo, um serviço definido com
requerimentos de disponibilidade 24x7 deve se
fundamentar em legados que o atendam.
• Deve-se definir um processo formal para a
análise do “gap” tecnológico.
• Eventualmente, projetos de SOA levam ao inicío
de outros projetos para aprimoramento (ou
troca) dos legados.
26
