Service-Oriented  ArchitectureService-Oriented Architecture   –   Claudio Acquaviva   1
Benefícios de SOA • TI flexível e ágil.      ─ “Time-to-Market” mais rápido. •   Processos de negócio passíveis de alteraç...
Quando Implementar SOA  • Ambiente com diversidade de legados que não se      comunicam.  •   Necessidade de diminuir depe...
Quando Não Implementar SOA   • Ambiente de TI homogêneo e padronizado.   • Performance “real-time” é crítica.   • Processa...
Arquitetura: Definição   • Uma arquitetura é um conjunto de componentes     tecnológicos (HW e SW) em um determinado     c...
Fato #1: SOA = Arquitetura • SO “Architecture”. SOA é uma arquitetura de serviços   de negócio. • “Service” OA. O que impo...
SOA - Finanças                          Camada de                        Apresentação e                           Acesso  ...
SOA - Telecomunicações                     Camada de                   Apresentação e                      Acesso         ...
Hierarquia de Serviços                                       Processo de Negócio                                          ...
Fato #2: SOA Não é Novo   • SOA é o conjunto de todas as melhores práticas     para    o    desenvolvimento    de   aplica...
Fato #3: SOA Deve Alinhar Tecnologia e Áreas de Negócio                                                      11
Requerimentos de um Serviço    • Um serviço responde por requisições através de       interfaces bem definidas, padronizad...
Aspectos Não-Funcionais   • Versionamento        ─ Funcional e formatos   •   “Throughput”        ─ Garantir o número de m...
Fato #4: SOA Necessita de Processos Formais e Específicos                                                                 ...
Arquiteto de Aplicações   • Responsável pela definição da arquitetura de     uma aplicação ou sistema.   • Conhecimentos e...
Fato #5: SOA Traz um Novo Perfil de Arquiteto  • Arquiteto Corporativo    ─ Normalmente não é o responsável pela      arqu...
Pequeno Exemplo de Arquitetura CorporativaCamada de Acesso                                        Balanc.                 ...
Arquiteto Corporativo      Analistas de                       Arquiteto de       Negócio                           Aplicaç...
Mito #1: SOA = Integração de Sistemas   • Integração de Sistemas      ─ Resolve problemas de integração de nível de       ...
Mito #2: SOA = Web Services   • Web Services      ─ Serviços e lógica de negócio são expostos de        forma fracamente a...
Modelo de Implementação de Serviços• Um dos modelos largamente usados para a  implementação da camada de serviços é aquela...
Mito #3: SOA = “Webficação” de Legado • “Webficação”    ─ “Casca” Web para acesso a aplicações existentes. • SOA    ─ É ma...
Mito #4: SOA = Serviços + BPM • A camada de serviços de negócio deve ser implementada para   ser consumida por quaisquer o...
Exemplo de Processo de Negócio                                 24
BPM e SOA            Projeto BPM            Projeto SOA                          25
Mito #5: Projetos de SOA Resolvem Problemas de Legado   • A Arquitetura de Serviços define um nível de     abstração novo....
Referências bibliográficas                             27
Service-Oriented  ArchitectureService-Oriented Architecture   –   Claudio Acquaviva   28
Nächste SlideShare
Wird geladen in …5
×

SOA - Fatos e Mitos

1.432 Aufrufe

Veröffentlicht am

Veröffentlicht in: Technologie
  • Als Erste(r) kommentieren

  • Gehören Sie zu den Ersten, denen das gefällt!

SOA - Fatos e Mitos

  1. 1. Service-Oriented ArchitectureService-Oriented Architecture – Claudio Acquaviva 1
  2. 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. 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. 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. 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. 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. 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. 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. 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. 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. 11. Fato #3: SOA Deve Alinhar Tecnologia e Áreas de Negócio 11
  12. 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 conjuntoConsumidor extenso Qualidades não funcionais do Serviço de aspectos Não-Funcionais Lógica de Negócio Funcional 12
  13. 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. 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 dd 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. 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. 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. 17. Pequeno Exemplo de Arquitetura CorporativaCamada de Acesso Balanc. Balanc. Firewall Firewall de Carga de Carga Serv. Serv. Portal Portal Web WebCamada 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. UsuariosCluster de AppSrvs Ecossistemas própriosCamada de Dados LDAP RDBMS Cluster RDBMS LDAP MS-AD Radius Kerberos Discos 17
  18. 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. 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. 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. 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. 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. 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
  24. 24. Exemplo de Processo de Negócio 24
  25. 25. BPM e SOA Projeto BPM Projeto SOA 25
  26. 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
  27. 27. Referências bibliográficas 27
  28. 28. Service-Oriented ArchitectureService-Oriented Architecture – Claudio Acquaviva 28

×