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, 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

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
Ávida por mudanças 2
Mais
inovadora que a imaginação dos clientes

3
Globalmente
integrada

4
Desbravadora
por natureza

5
Genuína,
não apenas generosa
3

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

Depto.

4

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

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

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

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

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

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

Os desafios dos profissionais de TI

Como ser mais ágil no desenvolvimento de novos produtos?

Como suportar modelos de negócios em constante mutação? Como diminuir os custos de desenvolvimento e manutenção? 11

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

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

Sistemas
Estruturados

Apresentação

Apresentação

Apresentação

Lógica de Negócio

Lógica de Negócio

Lógica de Negócio

Sistemas
Cliente/Servidor

Sistemas em três camadas
Apresentação
Lógica de Negócio

Dados

Dados

Dados
Dados

Pouca estruturação ou separação
Dependência
tecnológica

Estruturado, mas ainda fisicamente monolítico. Mais distribuído fisicamente, porém de uma forma não muito bem estruturada e ainda com dependências lógicas entre as camadas. Dependência tecnológica Dependência tecnológica Distribuído fisicamente, porém de uma forma menos estruturada do que a anterior e com dependências lógicas entre as camadas.

Dependência tecnológica Tempo
13

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)
Apresentação

Lógica de Negócio

Dados

Serviços
Apresentação

Lógica de Negócio

Dados
14

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

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

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

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 (latebinding), o que permite a mudança da fonte de aprovisionamento do serviço a cada momento de execução.
18

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

Níveis de abstração

Abstração

Serviço
Componente
Classe

20

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

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

Tipos de arquitetura

Consumidor

Arquitetura de Aplicação

Arquitetura de Serviços

Provedor
Arquitetura de
Componentes
23

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

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

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

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

Componentes vs. Serviços

28

Componentes vs. Serviços

29

Componentes vs. Serviços

30

Componentes vs. Serviços
Componentes
Apresentação

Lógica de Negócio

Dados

Serviços
Apresentação

Lógica de Negócio

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 implementação, portanto ainda há dependência tecnológica

Serviços bem descritos permitem o uso dinâmico e sem a necessidade de conhecimento da implementação, proporcionando independência de tecnologia
Organizações externas podem usar as mesmas interfaces, permitindo interoperabilidade e aumentando a flexibilidade.
31

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

“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;
• Economia de escala alcançável através do reúso dos componentes disponíveis;

das aplicações e pacotes existentes;
• Oportunidades de reúso e economia de escala;
• Caminho mais fácil para futuras reengenharias.

• A escolha de diferentes componentes pode render uma flexibilidade pré-implementação.
Potenciais desvantagens

Potenciais desvantagens
• Inflexibilidade por trás das interfaces de serviço;
• Aplicações e pacotes existentes preservam suas

• Componentes são permanentemente “assemblados” nas aplicações. É mais fácil “plugar” que “desplugar”
• Falta de flexibilidade pós-implementação

limitações legadas;
• Questões de escalabilidade e portabilidade da 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

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

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