Componentes
    vs.
  Serviços
   Marcelo Sávio
  Senior IT Architect
         IBM



                        1
O problema


• A mudança:

   Uma constante no mundo dos negócios;

   Fusões, aquisições, regulamentações de mercado, glo...
IBM Global CEO Study 2008


 O conhecimento coletivo dos CEOs apontou para os principais
 desafios da “Empresa do Futuro”
...
A necessidade de mudança nos processos de negócio

 Ex: Processo de pedido de compra




  Depto.




                    ...
A necessidade de mudança nos processos de negócio
 Ex: Processo de pedido de compra

  Cliente


  Depto.




            ...
A necessidade de mudança nos processos de negócio
 Ex: Processo de pedido de compra

  Cliente


  Depto.



  Serviço
  C...
A necessidade de mudança nos processos de negócio
 Ex: Processo de pedido de compra

  Cliente


  Depto.



  Serviço
  C...
A necessidade de mudança nos processos de negócio
 Ex: Processo de pedido de compra

  Cliente


  Depto.



  Serviço
  C...
A necessidade de mudança nos processos de negócio
 Ex: Processo de pedido de compra

  Cliente


  Depto.



  Serviço
  C...
A necessidade de mudança nos processos de negócio
 Ex: Processo de pedido de compra

  Cliente


  Depto.



  Serviço
  C...
Os desafios dos profissionais de TI




                       Como ser mais ágil      Como suportar
                     ...
As perspectiva técnica da mudança

• Para os desenvolvedores, mudanças têm sido consideradas como um mal a ser
  evitado, ...
Evolução das aplicações

  Sistemas             Sistemas              Sistemas              Sistemas em
 Monolíticos      ...
Evolução das aplicações

• As metodologias de desenvolvimento de software mais pragmáticas (e modernas)
  acreditam no pro...
Algumas idéias (clássicas) que levaram ao uso de componentes/serviços

•   Subrotinas
     1949, Alan Turing
     “Checkin...
Componentes vs. Serviços

• Discussão típica da introdução de um novo paradigma;
• A história das mudanças de paradigma na...
Componentes vs. Serviços


• Filosofia:

    A idéia do desenvolvimento baseado em componentes é a de
    “industrializar”...
Componentes vs. Serviços

• Binding:
 Uma característica comum a ambos é que as partes de um sistema
 podem ser desenvolvi...
Componentes vs. Serviços


• Granularidade e abstração:
 A granularidade é um conceito relativo. Refere-se à escala dos ar...
Níveis de abstração




                      Serviço
    Abstração



                      Componente
                  ...
Componentes vs. Serviços


• Mecanismo de distribuição:
    No modelo de componentes, a produção de software é orientada a...
Componentes vs. Serviços

• Arquitetura:

    Uma arquitetura de componentes é uma especificação de um
    conjunto de int...
Tipos de arquitetura
 Consumidor




              Arquitetura
              de Aplicação



                             ...
Desafios comuns

  Para alcançar flexibilidade através de componentes ou serviços é
  necessário transpor desafios (técnic...
Desafios comuns

• Gerenciamento da composição: Um dos grandes avanços no desenvolvimento
  de software diz respeito à cap...
Desafios comuns

• Especificação:

     Uma limitação importante na construção de software flexível está na maneira
     c...
Desafios comuns

• Eficiência da implementação:

     Praticamente todas as mudanças de paradigmas trouxeram questões
    ...
Componentes vs. Serviços




                           28
Componentes vs. Serviços




                           29
Componentes vs. Serviços




                           30
Componentes vs. Serviços

           Componentes                         Serviços
           Apresentação                 ...
Conclusão

• A evolução é uma capacidade crítica no ciclo de vida de um software,
  particularmente quando esse software a...
“Resumão”

        Componentes sem SOA                                       SOA sem Componentes
Benefícios Potenciais    ...
Referências bibliográficas

•   ELFATATRY, Ahmed. Dealing with Change: Components versus Services. Communications of
    t...
Obrigado pela atenção


      Perfil Linkedin: http://www.linkedin.com/in/msavio

      Perfil Plaxo: http://msavio.myplax...
Próximos SlideShares
Carregando em…5
×

Componentes vs Servicos

3.777 visualizações

Publicada em

Uma comparação entre duas abordagens de desenvolvimento de software: componentes serviços.

Publicada em: Tecnologia, Negócios
  • Seja o primeiro a comentar

Componentes vs Servicos

  1. 1. Componentes vs. Serviços Marcelo Sávio Senior IT Architect IBM 1
  2. 2. O problema • A mudança: Uma constante no mundo dos negócios; Fusões, aquisições, regulamentações de mercado, globalização, outsourcing, novas tecnologias, etc.; No longo prazo, quase todos os aspectos de um negócio são suscetíveis a mudanças. 2
  3. 3. IBM Global CEO Study 2008 O conhecimento coletivo dos CEOs apontou para os principais desafios da “Empresa do Futuro” Sumário do resultado das 1.130 entrevistas: As organizações são bombardeadas por mudanças, e muitas delas estão lutando para sobreviver; Os CEOs vêem os clientes cada vez mais exigentes não como ameaças, mas como uma oportunidade para se diferenciarem; Quase todos os CEOs estão adaptando seus modelos de negócio. E dois terços estão implementando grandes inovações; Os CEOs estão mudando agressivamente para projetos globais de negócio, alterando profundamente as capacidades e criando parcerias mais amplas. 1 2 3 4 5 Ávida por Mais Globalmente Desbravadora Genuína, mudanças inovadora integrada por natureza não que a apenas imaginação generosa dos clientes 3
  4. 4. A necessidade de mudança nos processos de negócio Ex: Processo de pedido de compra Depto. 4
  5. 5. A necessidade de mudança nos processos de negócio Ex: Processo de pedido de compra Cliente Depto. Mudança: Entrada de pedido de cliente via Web 5
  6. 6. A necessidade de mudança nos processos de negócio Ex: Processo de pedido de compra Cliente Depto. Serviço Compartilhado Mudança: Serviço compartilhado – ex. marketing, faturamento, jurídico 6
  7. 7. A necessidade de mudança nos processos de negócio Ex: Processo de pedido de compra Cliente Depto. Serviço Compartilhado Fornecedor Mudança: Fornecedor passa a cuidar do estoque 7
  8. 8. A necessidade de mudança nos processos de negócio Ex: Processo de pedido de compra Cliente Depto. Serviço Compartilhado Fornecedor Serviço Terceirizado Mudança: Entrega através de serviço de correio 8
  9. 9. A necessidade de mudança nos processos de negócio Ex: Processo de pedido de compra Cliente Depto. Serviço Compartilhado Fornecedor Serviço Terceirizado Mudança: recall terceirizado 9
  10. 10. A necessidade de mudança nos processos de negócio Ex: Processo de pedido de compra Cliente Depto. Serviço Compartilhado Fornecedor Serviço Terceirizado Mudança: Otimização de processo interno 10
  11. 11. Os desafios dos profissionais de TI Como ser mais ágil Como suportar no desenvolvimento modelos de negócios de novos produtos? em constante mutação? Como diminuir os custos de desenvolvimento e manutenção? 11
  12. 12. As perspectiva técnica da mudança • Para os desenvolvedores, mudanças têm sido consideradas como um mal a ser evitado, ao invés de uma oportunidade a ser explorada; • Por outro lado, a capacidade de lidar com mudanças significativas no design e no comportamento de um sistema ao longo do seu ciclo de vida é o principal diferenciador da engenharia de software das outras engenharias; • Flexibilidade É o termo geral que descreve a capacidade de um sistema de se adaptar às mudanças: Flexibilidade no momento do design: Absorção de mudanças no software (não apenas no código) minimizando os custos (tempo e esforço); Flexibilidade no momento do runtime: Absorção de mudanças nos requisitos sem mudanças no código. • Diversas abordagens de desenvolvimento e arquiteturas de sistemas surgiram ao longo dos anos para endereçar as constantes necessidades de mudanças. 12
  13. 13. Evolução das aplicações Sistemas Sistemas Sistemas Sistemas em Monolíticos Estruturados Cliente/Servidor três camadas Apresentação Apresentação Apresentação Apresentação Lógica de Negócio Lógica de Negócio Lógica de Negócio Lógica de Negócio Dados Dados Dados Dados Pouca estruturação Estruturado, mas Distribuído Mais distribuído ou separação ainda fisicamente fisicamente, porém de fisicamente, porém de monolítico. uma forma menos uma forma não muito Dependência estruturada do que a bem estruturada e ainda tecnológica Dependência anterior e com com dependências tecnológica dependências lógicas lógicas entre as entre as camadas. camadas. Dependência Dependência tecnológica tecnológica Tempo 13
  14. 14. Evolução das aplicações • As metodologias de desenvolvimento de software mais pragmáticas (e modernas) acreditam no processo incremental, no qual a mudança é um aspecto inevitável e pode ocorrer em qualquer estágio de um sistema; • Os sistemas precisam estar em constante evolução e a separação entre o desenvolvimento e a manutenção de um sistema tornou-se cada vez menos significante; • Duas abordagens (recentes) para design de software surgiram com a capacidade de alavancar o reúso e suportar a evolução contínua dos sistemas: Componentes (Distribuídos) Serviços Apresentação Apresentação Lógica de Negócio Lógica de Negócio Dados Dados 14
  15. 15. Algumas idéias (clássicas) que levaram ao uso de componentes/serviços • Subrotinas 1949, Alan Turing “Checking a Large Routine” • Componentes de software 1967, Ivar Jacobson (então funcionário da Ericsson) propôs o uso de componentes de software no design da nova geração de switches telefônicos controlados por computador. • Disseminação do uso de componentes de software na indústria de TI 1968, Douglas McIlroy (Conferência da OTAN sobre Engenharia de Software) “Mass Produced Software Components” • Libraries 1971, Numerical Algorithms Group (NAG) Libraries para FORTRAN e ALGOL • Information Hiding 1972, David Parnas “On the Criteria to Be Used in Decomposing Systems Into Modules” • Separation of Concerns 1974, Edsger Dijkstra "On the role of scientific thought" • Design by Contract 1986, Bertrand Meyer “Technical Report TR-EI-12/CO” 15
  16. 16. Componentes vs. Serviços • Discussão típica da introdução de um novo paradigma; • A história das mudanças de paradigma na ciência e na tecnologia é repleta de situações semelhantes; • Alguns exemplos no mundo do desenvolvimento de sistemas: Componentes vs. Objetos; Objetos vs. Programação estruturada; Programação estruturada vs. Programação procedural; Programação de alto nível vs. Programação de baixo nível; etc. 16
  17. 17. Componentes vs. Serviços • Filosofia: A idéia do desenvolvimento baseado em componentes é a de “industrializar” o processo de desenvolvimento de software, através da “assemblagem” de componentes pré-fabricados; No modelo de serviços há uma total separação lógica entre uma necessidade e seu respectivo mecanismo de atendimento (baixo acoplamento); O conceito de serviço difere do de componente pelo fato de que um serviço não define nenhuma limitação estrutural, a não ser a sua interface. 17
  18. 18. Componentes vs. Serviços • Binding: Uma característica comum a ambos é que as partes de um sistema podem ser desenvolvidas separadamente e adicionadas ao sistema posteriormente; Ainda que os modelos orientado a componentes e serviços compartilhem características comuns, existem diferenças: Um software cujo desenvolvimento tenha sido orientado a componentes adota o early-binding dos componentes, ou seja, a unidade responsável pelas chamadas sabe exatamente quais componentes deverão ser contactados antes da execução; O desenvolvimento orientado a serviços adota uma abordagem mais flexível, na qual o binding acontece no momento de execução (late- binding), o que permite a mudança da fonte de aprovisionamento do serviço a cada momento de execução. 18
  19. 19. Componentes vs. Serviços • Granularidade e abstração: A granularidade é um conceito relativo. Refere-se à escala dos artefatos que precisam ser mudados, variando dos mais genéricos (coarse grained) aos bem específicos (fine grained); O paradigma da orientação a objetos não foi suficiente para lidar com as mudanças (too fine grained e não havia uma separação clara entre os aspectos computacionais e a composição dos objetos). Os componentes então foram propostos, de forma a encapsular os detalhes computacionais de um conjunto de objetos; Em relação aos componentes, os serviços possuem um grau de abstração ainda maior, no qual são representadas atividades do mundo real ou funções de negócio. Os serviços normalmente possuem uma granularidade relativamente genérica e suportam um único conceito ou processo de negócio. 19
  20. 20. Níveis de abstração Serviço Abstração Componente Classe 20
  21. 21. Componentes vs. Serviços • Mecanismo de distribuição: No modelo de componentes, a produção de software é orientada a produto, podendo inclusive ser entregue em algum formato de mídia; No modelo de serviços as funcionalidades de software são entregues como serviços, os quais, quando são requisitados, têm seus elementos identificados, seus termos e condições negociados, é executado e depois “descartado”. Esse modelo oferece uma maior flexibilidade para lidar com mudanças. 21
  22. 22. Componentes vs. Serviços • Arquitetura: Uma arquitetura de componentes é uma especificação de um conjunto de interfaces e regras de interação que governam a comunicação entre componentes. A maioria das arquiteturas de componentes possui um forte acoplamento entre seus elementos (ex. CORBA); Uma arquitetura orientada a serviços (SOA) permite projetar sistemas de software capazes de prover serviços para aplicações (ou outros serviços) através de interfaces publicadas e descobertas automaticamente. Os consumidores dos serviços são desacoplados dos provedores, normalmente intermediados por um broker; Tipicamente uma camada de serviços é montada sobre uma camada de componentes. 22
  23. 23. Tipos de arquitetura Consumidor Arquitetura de Aplicação Arquitetura de Serviços Provedor Arquitetura de Componentes 23
  24. 24. Desafios comuns Para alcançar flexibilidade através de componentes ou serviços é necessário transpor desafios (técnicos e não técnicos): • Confiança: No contexto de software significa que o componente ou serviço irá prover todas as obrigações funcionais e não-funcionais conforme “prometido” em sua descrição. Testar um componente ou serviço pela análise de seu código não é algo prático. Mudanças no código podem invalidar a especificação contratual de um componente ou serviço. Os componentes, mesmo de origem desconhecida, podem ser testados diversas vezes antes de serem usados. A seleção ocorre no momento de design de um sistema, o qual poderá, posteriormente, necessitar alguma adaptação (“glue code”); No desenvolvimento baseado em serviços, a descoberta e seleção de serviços ocorre no momento de execução, o que torna o “testar-antes-de-usar” praticamente impossível, já que a origem de um serviço, assim como suas condições de uso podem variar entre duas invocações consecutivas. Adicionalmente é necessário monitorar o SLA (Service Level Agreement), o que se torna mais complicado quando o serviço é composto por outros serviços. 24
  25. 25. Desafios comuns • Gerenciamento da composição: Um dos grandes avanços no desenvolvimento de software diz respeito à capacidade de criar sistemas através da composição de elementos pré-existentes. Isso, entretanto, gera preocupações com a gestão dessa composição: Fazer um sistema através da composição de um certo número de componentes é algo relativamente controlável, quando comparado com a composição dinâmica que acontece em uma arquitetura de serviços; À medida que os provedores de serviço os expõem em um sistema distribuído, mais se torna inviável gerenciar e compor serviços manualmente; Quanto mais aberto (não controlado) for o ambiente distribuído, mais complexas serão as questões relacionadas à semântica das transações, aos mecanismos de rollback e ao licenciamento e cobrança por uso. 25
  26. 26. Desafios comuns • Especificação: Uma limitação importante na construção de software flexível está na maneira com a qual os componentes são especificados. Uso de padrões proprietários e de especificações dependentes da implementação são os principais inibidores para o desenvolvimento orientado a componentes alcançar os objetivos mais amplos de reúso; O principal ponto de uma arquitetura SOA é a especificação dos serviços e não a sua implementação, o que provê uma maior transparência e minimiza os impactos da mudança nos sistemas. A capacidade de descoberta automática existente no modelo de desenvolvimento baseado em serviços é o avanço mais significativo quando o comparamos ao modelo de desenvolvimento baseado em componentes. 26
  27. 27. Desafios comuns • Eficiência da implementação: Praticamente todas as mudanças de paradigmas trouxeram questões relacionadas à eficiência de implementação e já está melhor resolvido no desenvolvimento de componentes; O conceito de late-binding, que é crucial em uma arquitetura SOA, geralmente provoca overhead, especialmente se a descoberta e a seleção de um serviço acontecem a cada vez que as funcionalidades são invocadas. 27
  28. 28. Componentes vs. Serviços 28
  29. 29. Componentes vs. Serviços 29
  30. 30. Componentes vs. Serviços 30
  31. 31. Componentes vs. Serviços Componentes Serviços Apresentação Apresentação Lógica de Negócio Lógica de Negócio Dados Dados Estruturado e com separação Estruturado e com separação Encapsulamento e uso de Interfaces Encapsulamento e uso de Interfaces Uso requer conhecimento da Serviços bem descritos permitem o uso dinâmico implementação, portanto ainda há e sem a necessidade de conhecimento da dependência tecnológica implementação, proporcionando independência de tecnologia Organizações externas podem usar as mesmas interfaces, permitindo interoperabilidade e aumentando a flexibilidade. 31
  32. 32. Conclusão • A evolução é uma capacidade crítica no ciclo de vida de um software, particularmente quando esse software atende a domínios de negócio mais voláteis. Essa capacidade pode ser suportada tanto pelo desenvolvimento orientado a componentes quanto a serviços; • Componentes e serviços, ainda que tenham muitas similaridades, possuem diferentes filosofias e níveis de abstrações, que fazem do desenvolvimento orientado a serviços uma melhor abordagem para lidar com as mudanças; • Mas nem todo software é apropriado a ser desenvolvido baseado em serviços, sendo essa abordagem mais recomendada nos casos em que a mudança de requisitos é mais freqüente e a tolerância à ineficiência de implementação é maior; • O uso de componentes é uma ótima maneira de se implementar serviços (ainda que um sistema orientado a componentes “ideal” possa não resultar em um sistema orientado a serviços “ideal”); • Serviços não substituem os componentes, mas os complementam. 32
  33. 33. “Resumão” Componentes sem SOA SOA sem Componentes Benefícios Potenciais Benefícios Potenciais • As soluções de software são desenvolvidas • Serviços são desenvolvidos rapidamente, a partir rapidamente, a partir dos componentes existentes; das aplicações e pacotes existentes; • Economia de escala alcançável através do reúso • Oportunidades de reúso e economia de escala; dos componentes disponíveis; • Caminho mais fácil para futuras reengenharias. • A escolha de diferentes componentes pode render Potenciais desvantagens uma flexibilidade pré-implementação. • Inflexibilidade por trás das interfaces de serviço; Potenciais desvantagens • Aplicações e pacotes existentes preservam suas • Componentes são permanentemente “assemblados” limitações legadas; nas aplicações. É mais fácil “plugar” que “desplugar” • Questões de escalabilidade e portabilidade da • Falta de flexibilidade pós-implementação implementação; • Reengenharia talvez nunca aconteça. Componentes e SOA O verdadeiro potencial dos componentes e serviços ocorre quando combinamos essas duas abordagens: • Componentes e serviços assemblados com baixo acoplamento e re-acoplamento dinâmico; • Interfaces de serviços coerentes e suportadas por aplicações flexíveis baseadas em componentes; • Abordagem baseada em serviço se aplica tanto dentro quanto fora das aplicações; • Melhor atendimento aos requisitos de negócio com soluções sob-demanda mais escaláveis. 33
  34. 34. Referências bibliográficas • ELFATATRY, Ahmed. Dealing with Change: Components versus Services. Communications of the ACM (50:8), 2007, pp. 35-39. • BUDGEN, D., BRERETON, P., TURNER, M. Codifying a service architectural style. In Proceedings of the 28th Annual International Computer Software and Applications Conference, Hong Kong, 2004. IEEE, 16–22. • BENNET, K., LAYZELL, P., BUDGEN, D., BRERETON, P., MACAULAY, L., MUNRO, M. Service-based software: The future for flexible software. In Proceedings of the 7th Asia-Pacific Software Engineering Conference, IEEE, Singapore, 2000. • ORMAN, Levent, Service Semantics, Structure, and Design. Johnson School Research Paper Series No. 06-07. Cornell University, 2008. Disponível em http://ssrn.com/abstract=1019041. Vistado em 7 dez 2008. • MYERS, Ware, "Ivar Jacobson: Shaping Software Development," IEEE Software, vol. 19, no. 3, pp. 93-95, May/June 2002, doi:10.1109/MS.2002.10016 • WILKES, Lawrence, SPROTT, David. Understanding Service Oriented Architecture. CBDI Forum, 2004. Disponível em http://msdn.microsoft.com/en-us/library/aa480021.aspx. Visitado em 7 nov 2009. • IBM Global Business Services. The Enterprise of the future. CEO Study 2008. Disponível em http://www.ibm.com/enterpriseofthefuture. Visitado em 7 nov 2009. 34
  35. 35. Obrigado pela atenção Perfil Linkedin: http://www.linkedin.com/in/msavio Perfil Plaxo: http://msavio.myplaxo.com/ Repositório de palestras: http://www.slideshare.net/msavio/slideshows Blog: http://betarrabios.blogspot.com/ Twitter: http://twitter.com/msavio Repositório de textos: http://www.scribd.com/msavio 35

×