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

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

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. 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. A necessidade de mudança nos processos de negócio
Ex: Processo de pedido de compra
Depto.
4

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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. Níveis de abstração
Serviço
Abstração
Componente
Classe
20

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. 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. Tipos de arquitetura
Consumidor
Arquitetura
de Aplicação
Arquitetura
de Serviços
Provedor
Arquitetura de
Componentes
23

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. 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. 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. 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. Componentes vs. Serviços
28

29. Componentes vs. Serviços
29

30. Componentes vs. Serviços
30

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. 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. “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. 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. 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