UM ESTUDO COMPARATIVO ENTRE SOA E POO
1
Eduardo Augusto Silvestre, 2Lucilene Aparecida de Oliveira
Instituto Federal do Triângulo Mineiro (IFTM) – Campus Avançado Patrocínio, Patrocínio – MG,
1
[email protected], [email protected]
Resumo – SOA (Service Orientation Architecture) é
um estilo arquitetural para a construção de soluções
corporativas baseadas em serviços. Na literatura existe
muita confusão e disputa entre SOA e a Programação
Orientada a Objetos (POO). Neste trabalho, pretende-se
desmistificar as diferenças e similaridades entre ambos.
Para isso, serão apresentados os principais conceitos
relacionados a SOA e a orientação a objetos. Também
será feito uma comparação entre ambos através da
perspectiva de diversos autores. Na parte final, conclui-se
que SOA e POO na verdade não são rivais e não
disputam o mesmo espaço.
Palavras-Chave – Service Oriented Architecture,
Programação Orientada a Objetos, Estilo Arquitetural
A COMPARATIVE STUDY AMONG SOA
AND OOP
Abstract - SOA (Service Orientation Architecture) is
an architectural style for constructing enterprise solutions
based on services. In literature there is much confusion
and dispute between SOA and Object-Oriented
Programming (OOP). This work aims to demystify the
differences and similarities between them. For this, we
will present the main concepts related to SOA and objectorientation. Also a comparison will be done both through
the perspective of many authors. In the end, it appears
that SOA and OOP are not really rivals and not compete
in the same space.
Keywords - Service Oriented Architecture, Object
Oriented Programminc, Architectural Sttyle.
I. INTRODUÇÃO
A programação orientada a serviços (OS), representa uma
nova plataforma de computação distribuída. Esta por sua vez,
envolvem muitos fatores, incluindo paradigmas e princípios
de projetos, catálogos e linguagens padrões do projeto, um
modelo arquitetural distinto, conceitos, tecnologias e
frameworks [1].
_______________________
Já Arquitetura Orientada a Serviços (SOA), ou, em ingles,
Service-Oriented Architecture é um termo que descreve duas
coisas muito distintas. As duas primeiras palavras, ServiceOriented, expressam uma metodologia para desenvolvimento
de software. E a terceira palavra, Architecture ou Arquitetura,
é um panorama de todos os ativos de software de uma
empresa, assim como uma planta arquitetônica é uma
representação de todas as peças que, juntas, formam uma
construção. Portanto, ―service-oriented architecture‖ é uma
estratégia que proclama a criação de todos os ativos de
software de uma empresa via metodologia de programação
orientada a serviços.
Existem pontos de confusão entre SOA e o uso do termo
OS, entre os principais enganos tem-se [2]: uma aplicação que
usa Web Services (WS) é OS; SOA é apenas uma estratégia de
TI, um termo de marketing usado para marcar WS, e sua
computação distribuída; o termo SOA simplifica este tipo de
computação.
Há alguns benefícios tangíveis em relação a SOA, como
[2]: integração melhorada -resultar na criação de serviços
inerentemente interoperáveis; reuso inerente; soluções e
arquiteturas alinhadas; investimento legado aproveitado;
estabelecimento de uma representação de dados padronizado
(XML); foco de investimento na comunicação da infraestrutura; agilidade organizacional.
II. HISTÓRICO
SOA surgiu nos últimos anos como uma das abordagens
preferidas para projeto de sistemas. Aproveitando padrões
abertos e a presença da internet, ela é baseado na utilização de
serviços reutilizáveis que correspondem a unidades lógicas de
trabalho auto-contidas. A promessa é que esses serviços
podem ser agrupados rapidamente usando padrões comuns
para formar novas aplicações que estão alinhadas com as
necessidades do negócio [3].
Em [3] é apresentado uma introdução sobre os conceitos e
tecnologias que antecederam essa nova arquitetura e também
quem criou o termo. Já em [4] são apresentadas uma
introdução ao termo e a dificuldade de definir SOA com
precisão.
Os sistemas mainframe das décadas de 1960 e 1970
raramente se comunicavam um com o outro. De fato, um dos
principais pontos de um mainframe era que ele forneceria
tudo necessário para realizar funções de computação em um
negócio [3].
Nos anos de 1980, computadores pessoais explodiram no
ambiente e os desenvolvedores procuravam formas mais
eficazes para alavancar o poder de computação dos
computadores pessoais. Como o preço do hardware diminuiu,
o número de servidores dentro da empresas aumentou
exponencialmente [3]. Essas evoluções, junto com a
maturidade crescente do Remote Procedure Call (RPC),
levaram a dois avanços importantes na computação
distribuída. O primeiro a tecnologia Common Object Request
Broker Architecture (CORBA,) que é uma arquitetura padrão
criada pelo Object Management Group (OMG) para
estabelecer e simplificar a troca de dados entre sistemas
distribuídos heterogêneos. O segundo é o Distributed
Computing Object Model (DCOM), que é uma tecnologia
proprietária da Microsoft para comunicação entre
componentes de software distribuídos em todos os
computadores em uma rede [3].
Até o final dos anos 1990 [3], com a adoção da Internet, as
empresas começaram a reconhecer os benefícios de ampliar
sua plataforma de computação para parceiros e clientes.
Anteriormente, a comunicação entre as organizações era
altamente onerosa e havia a necessidade de contar com linhas
privadas (leased lines). Sendo que essas eram impraticáveis,
exceto para as grandes empresas.
Os conceitos que hoje são associados com SOA surgiram
com a expansão e adoção da Internet e mais especificamente
do protocolo HTTP [3].
Muitos frameworks baseados em componentes tentaram
objetivos similares aos de SOA. Entretanto esta arquitetura
difere em algumas características dessa abordagem [3]:
CORBA, EJB, DCOM são baseados em tecnologias RPC, o
que encoraja o alto acoplamento, contrariando os princípios
de SOA que presa baixo acoplamento.
Surpreendentemente, é difícil descobrir quem criou o termo
SOA [4]. O momento atual do SOA foi criado pelos Web
Services, que inicialmente era dirigido pela Microsoft,
alcançaram um público amplo em 2000 [4]. Logo, outras
companhias e grandes vendedores (como IBM, ORACLE,
HP, SAP e SUN) aderiram a essa tendência. Um novo
mercado surgia com os novos conceitos e ferramentas (ou
conceitos reinventados e ferramentas). Além disso, o tempo
estava certo, porque as companhias estavam cada vez mais
integrando seus negócios com outros sistemas, departamentos
e companhias.
Posteriormente os analistas começaram a olhar SOA como
um conceito chave para software no futuro. Um estudo feito
por [5] chegou à conclusão que em 2008, SOA forneceria
80% da base de todos os projetos de desenvolvimento.
No entanto cada movimento cria grandes críticas devido ao
exagero usado no termo. Grady Booch, um dos idealizadores
da UML fez o seguinte comentário em 2006 em seu blog [6]:
“Minha opinião sobre toda a cena que acontece com SOA
é mais ousada do que eu tenho visto. Muito do que se fala
sobre SOA fica parecendo que SOA é a melhor coisa que
existiu desde os cartões perfurados. SOA não irá
aparentemente transformar sua organização e fazer você
mais ágil e inovador.”
Booch estava certo. Pois é importante lembrar que SOA é
uma estratégia que requer tempo e esforço. É necessário
alguma experiência para entender o que SOA realmente é,
onde, e como ela ajuda.
III. CONCEITOS RELACIONADOS
A. Arquitetura
Normalmente, poucos programas de computador são
suficientes para atender a uma empresa pequena ou
organização. Estes pequenos programas são fáceis de gerir e
não há necessidade de um projeto global. No entanto, quando
são consideradas organizações maiores, o número de
programas de computador cresce e existe maior necessidade
de um projeto global ou desenho da estratégia com o objetivo
de evitar o caos. Este projeto global ou estratégia de projeto é
chamado de arquitetura de software [7].
Arquitetura é a caracterização da organização do sistema
em termos das suas partes constituintes. Ela caracteriza a
estrutura física, organização funcional e o comportamento
colaborativo das suas partes constituintes e os relaciona à
finalidade do sistema. Uma descrição arquitetural completa
serve como referência para os stakeholders, como eles se
esforçam para assegurar que os sistemas que são feitos,
satisfazem a finalidade que motivou a sua construção [9].
Arquitetura de Software engloba as decisões importantes
sobre [10] [11]:

A organização de um sistema de software.

A seleção dos elementos estruturais e suas
interfaces, que o sistema é composto.

A composição desses elementos em subsistemas
progressivamente maiores.

O estilo arquitetural que guia essa organização,
esses elementos e suas interfaces, suas colaborações e sua
composição.
A arquitetura de software não está preocupada somente
com a estrutura e comportamento, mas também com o uso,
funcionalidade,
desempenho,
robustez,
reutilização,
compreensão, restrições econômicas e tecnológicas, tradeoffs
e estética [10] [11].
B. Serviço
A palavra serviço refere-se a uma pessoa realizando algum
trabalho ou tarefa para alguém. Uma definição superficial
mais genérica para serviço é uma pessoa ou organização
realizando algum trabalho para outra pessoa ou organização
[7]. Um serviço é um componente de software que tem as
seguintes propriedades [8]:

É definido por uma interface que pode ser
independente da plataforma.

Está disponível através de uma rede.

As operações definidas na interface executam as
funções de negócio.
Sua interface e sua implementação podem ser decoradas
com extensões que tem efeito em tempo de execução.
C. SOA
SOA é um estilo de arquitetura que usa serviços como
blocos de construção para facilitar a integração da empresa e
reuso de componentes através de baixo acoplamento [8] e
para a construção de soluções corporativas baseadas em
serviços. Mais especificamente, esta arquitetura está
preocupada com a construção independente de serviços
alinhados aos negócios que podem ser combinadas em
processos de negócios de alto nível e soluções dentro do
contexto de uma empresa [10].
Existem alguns conceitos técnicos sobre SOA que
permitem lidar com diversas características de sistemas [4]:
 Alta interoperabilidade: com sistemas heterogêneos, o
primeiro objetivo é ser capaz de conectar esses sistemas, ou
seja, interagir e comunicar com outro. Esse processo é
chamado de ―alta interoperabilidade‖. Para SOA essa
característica é a base para começar a implementar
funcionalidades de negocio (serviços) que esta espalhada por
diversos sistemas distribuídos.
 Baixo acoplamento: é o conceito de minimizar as
dependências, ou seja, está relacionado com a sua capacidade
de ser independente de outros serviços para realizar a sua
tarefa. Alem do baixo acoplamento, é importante que um
serviço tenha alta coesão, ou seja, a sua atividade seja bem
definida e coerente.
 Serviços: descrito anteriormente.
SOA modulariza informações do sistema dentro de
serviços. Em um projeto bem executado, pode-se facilmente
recombinar esses serviços de várias maneiras para
implementar um processo de negócio novo ou melhorado [9].
Este tipo de arquitetura tem um processo evolutivo das
técnicas de modularização de software que começaram há
mais de 50 anos com a introdução da programação
estruturada. A novidade do SOA é que ele oferece aumento na
flexibilidade na escolha das tecnologias de implementação e
locais para os fornecedores de serviço e consumidores. A
interface de serviços abstrata também habilita fornecedores e
consumidores a se envolverem independentemente - contanto
que as interfaces permaneçam estáveis [9].
composição e interação entre diversas unidades de software
chamadas de objetos [14].
POO é a programação implementada pelo envio de
mensagens a objetos. Cada objeto irá responder às
mensagens conhecidas por este, e cada objeto poderá enviar
mensagens a outros, para que sejam atendidas, de maneira
que ao final do programa, todas as mensagens enviadas
foram respondidas, atingindo-se o objetivo do programa.
POO, técnicas e artefatos ditos ―orientados a objetos‖
incluem linguagens, sistemas, interfaces, ambientes de
desenvolvimento, bases de dados, etc [16].
Algumas das vantagens que motivam programadores a
utilizar o para o paradigma de orientação a objeto são [17]:

Redução no custo de manutenção: existem
características (herança e encapsulamento) que permitem
que, quando for necessária alguma alteração, modifique-se
apenas o objeto que necessita desta alteração, e ela propagarse-á automaticamente às demais partes do software que
utilizam este objeto.

Aumento na reutilização de código: pode-se dizer,
de modo simplório, que o conceito de orientação a objetos
(OO) fornece a possibilidade de um objeto acessar e usar
como se fossem seus os métodos e a estrutura de outro
objeto. Deste modo, quando, por exemplo, existirem dois
objetos bastante semelhantes, com mínimas diferenças, podese escrever os métodos apenas uma vez e usá-los para os dois
objetos. Apenas os métodos que realmente forem diferentes
para os dois objetos é que precisam ser escritos
individualmente.
D. Separação de Interesses
A separação de interesses (separation of concerns) é o
princípio mais fundamental da SOA. Os interesses são
mantidos separados para que os elementos independentes
permaneçam independentes. O benefício é que uma mudança
em uma parte do sistema não altera outras partes. Em outras
palavras, eles podem ser modificados independentemente.
Um exemplo familiar desse princípio é a separação da
interface da implementação [10].
Ou seja, baseado na teoria de Separação de Interesses,
―quebrando‖ um problema grande e complexo em uma série
de pequenos problemas, como ilustrado na Fig. 1:
A OO é um paradigma de análise, projeto e programação
de sistemas de software baseado na composição e interação
entre diversas unidades de software chamadas de objetos. A
análise e projeto OO têm como meta identificar o melhor
conjunto de objetos para descrever um sistema de software.
O funcionamento deste sistema se dá através do
relacionamento e troca de mensagens entre estes objetos. Na
programação orientada a objetos, implementa-se um conjunto
de classes que definem os objetos presentes no sistema de
software.
Serão apresentadas algumas comparações entre Sistemas
OO e Sistemas OS, nas próximas linhas. Primeiramente, são
mostradas comparações feitas por Thomas Erl – onde
conceitos básicos de OO são comparados com conceitos de
OS. Posteriormente, Dan Woods e Thomas Mattern explicam
o porquê, segundo eles, OS é melhor que OO. Finalmente,
Nicolai M. Josuttis faz uma comparação direta focada entre
SOA e POO.
O paradigma OO é composto de um conjunto rico de
princípios de projeto fundamentais que estruturam e
organizam a lógica OO através das classes. Alguns desses
princípios foram carregados para orientação a serviços e,
outros não [1]. Os princípios da orientaçãoa objetos
comparados com a orientação a serviços são mostrados na
Tabela I.
Fig. 1. Modelo de Separação de Interesses
E. POO
A orientação a objetos é um paradigma de análise, projeto
e programação de sistemas de software baseado na
IV. ESTUDO COMPARATIVO
TABELA I
Comparação dos princípios de OO com OS
OO
OS
OO
OS
OO
OS
OO
OS
OO
OS
OO
OS
CLASSES
Em OO classe é representado como um conjunto
de objetos com características comuns.
Uma classe é comparável, mas não equivalente a
um contrato de serviço técnico. Uma classe pode
definir uma combinação de acesso público e
privado aos detalhes de implementação,
enquanto que um contrato de serviço expressa
apenas informação pública. Nesse sentido, um
contrato de serviço é mais parecido com uma
interface implementada por uma classe.
OBJETOS
Um objeto é capaz de armazenar estados através
de seus atributos e reagir a mensagens enviadas a
ele, assim como se relacionar e enviar
mensagens a outros objetos
Uma instância em tempo de execução de uma
classe é um objeto, assim como uma instância
em tempo de execução de um serviço é
uma instância de serviço.
METÓDOS E ATRIBUTOS
Em OO eles são usados para associar um
comportamento
e
dados
dos
objetos
respectivamente.
Em OS eles manifestam os comportamentos
como capacidades abstratas. A capacidade é o
equivalente de um método se um serviço é
implementado como um componente e uma
operação se um serviço é implantado como um
WS.
MENSAGENS
É uma chamada a um objeto para invocar um de
seus métodos, ativando um comportamento
descrito por sua classe.
As mensagens utilizadas pelos serviços
implementados
como
WS
normalmente
manifestam-se como unidades com base em
texto de comunicação, que podem ser trocadas
(sincronament ou assincronamente).
INTERFACE
É um contrato entre a classe e o mundo externo.
Em OO as coleções de métodos relacionados
podem ser definidos (mas não implementados)
dentro de uma interface.
Em OS concentra-se sobre a definição do
contrato de serviço e sua solução lógica básica.
ENCAPSULAMENTO
A separação de aspectos internos e externos de
um objeto é chamada de encapsulamento. Em
OO a noção deste esta ligada ao ocultamento de
informação.
O princípio é válido para OS, que está
interessado em ocultar informações sobre os
serviços.
OO
OS
OO
OS
OO
OS
OO
OS
HERANÇA
É o mecanismo pelo qual uma classe pode
estender outra classe, aproveitando seus
comportamentos e variáveis possíveis.
Em OS é desencorajado a utilização de herança
entre serviços, porque há uma ênfase na
autonomia individual de um serviço e reduzido
acoplamento entre serviços.
GENERALIZAÇÃO
Em OO a generalização é realizada quando uma
super-classe pai é definida. As sub-classes da
classe pai (especializadas) implementam
variações distintas de uma super-classe, essa
definição é referenciada como especialização.
Existem conceitos similares de generalização e
especialização dentro da orientação a serviços.
ABSTRAÇÃO
É a habilidade de concentrar nos aspectos
essenciais de um contexto qualquer, ignorando
características menos importantes ou acidentais.
Em OO o conceito de abstração também está
relacionado ao ocultamento de informação.
Conceitualmente, abstrações em OS são
similares a OO. Entretanto, como OS não
fornecem herança não existe uma noção
correspondente a classe abstrata.
POLIMORFISMO
Em OO, polimorfismo consiste em 4
propriedades:

Universal:
1Inclusão;
2Paramétrico.

Ad-Hoc:
3Sobrecarga;
4Coerção.
Como não existe herança na OS essa forma de
polimorfismo também não é aplicada a serviços
individuais.
A OO é um poderoso paradigma de programação em que
as aplicações são expostas funcionalmente através de
interfaces bem definidas chamadas de métodos. No entanto, a
aplicação chamada precisa ser escrita na mesma linguagem
do objeto que está tentando acessar. Se não for, é preciso de
um programa tradutor como mostrado na Fig. 2 [13].
Fig 2. OO e Interoperabilidade
Os WS fornecem uma forma padrão para a comunicação
entre os serviços, que podem ser escritos em linguagens
diferentes, como é mostrado na Fig. 3 [13].
Baixo acoplamento
de serviço
Abstração de
Serviços
Fig 3. OS e Interoperabilidade
Existem duas perguntas muito comuns, se SOA substitui
POO ou qual deles é o melhor. Uma resposta interessante é
dada no livro Enterprise SOA, por Dan Woods e Thomas
Mattern (O'Reilly). Sob a seção intitulada "Por que OS é
melhor do que OO ?" Dois pontos aparecem. A primeira
explica OO com a seguinte limitação: "No entanto, o
aplicativo de chamada deve ser redigida na mesma
linguagem que o objeto que está tentando acessar." O
segundo parágrafo é constituído de uma única frase: "WS
fornecem uma forma padrão para se comunicar entre os
serviços, que podem ser escritos em linguagens diferentes
[4]."
―Toda esta discussão, é claro, é um desperdício. A
comparação entre SOA e POO simplesmente não faz sentido,
porque eles têm finalidades diferentes [4].‖
Nem SOA nem POO é melhor ou substitui a outra. POO é
um paradigma de programação de aplicações, enquanto que
SOA é um paradigma de arquitetura para ambientes de
sistemas. SOA é a abordagem a utilizar para conectar os
sistemas de escritos em paradigmas OO e outros. Em outras
palavras, a menos que seja gerado um único programa, você
precisa de ambos [4].
Componibilidade
de Serviço
Autonomia de
Serviço
O acoplamento em geral, é uma
das qualidades principais de OS
que se desvia da OO.
A abstração de serviços tem como
finalidade ocultar os detalhes
subjacentes ao serviço, de modo
que apenas o contrato do serviço
esteja disponível.
OO
suporta
conceitos
de
associação, tais como agregação e
composição. Estes, dentro de um
contexto de baixo acoplamento,
também são suportados pela OS.
A qualidade de autonomia é mais
enfatizada em OS, do que em
OO.
Nicolai M. Josuttis [4] chega mais perto da realidade na
tentativa de comparar SOA e POO. Porque não faz muito
sentido esta comparação, pois são coisas diferentes.
Enquanto POO trata das características internas de um
sistema, SOA está mais relacionado à comunicação externa.
OO se preocupa com a flexibilidade e abstração, ao passo
que SOA está preocupado com conformidade com normas,
simplicidade, protocolos e refere-se tanto como estratégia de
negócios como um projeto de arquitetura baseado em
serviços de software. SOA não é um substituto de OO, sendo
este ultimo a melhor opção para projetos de aplicativos e
componentes.
REFERÊNCIAS BIBLIOGRÁFICAS
V. CONCLUSÕES
SOA não apresenta nenhum conceito novo. É um
paradigma que traz consigo conceitos existentes e práticas
específicas para um conjunto de requisitos.
Procurando na literatura – livros, artigos de conferências,
blogs especializados – são encontrados algumas comparações
entre SOA e POO. Mas, poucos materiais têm algo formal,
bem definido, separado e organizado.
SOA e POO tem alguns objetivos semelhantes como o
aumento da robustez, da extensibilidade, da flexibilidade, da
reutilização e da produtividade. Como mostrado acima – pela
comparação dos termos inerentes a OO com OS -, ambos tem
algumas similaridades, mas não são a mesma coisa, como
pode ser visto na Tabela II.
TABELA II - PRINCÍPIOS COMUNS DA OO
RELACIONADOS COM OS
Princípios de OS
Reutilização de
Serviços
Contrato de
serviço
Princípios da OO
relacionados
Grande parte da OO é voltada para
a criação de classes reutilizáveis.
A reutilização de serviço é uma
continuação deste objetivo.
Assim como as definições WSDL,
as interfaces fornecem um meio
de abstrair a descrição de uma
classe.
[1]
[2]
[3]
[4]
[5]
[6]
[7]
[8]
[9]
[10]
[11]
[12]
Thomas Erl. SOA Principles of Service Design. Prentice
Hall, 2007.
Thomas Erl. Service-Oriented Architecture: Concepts,
Technology, and Design. Prentice Hall, 2005.
J, Davis. Open Source SOA. Manning, 2009.
N. M. Josuttis. SOA in Practice The Art of Distributed
System Design. O’Reilly, 2007.
Gartner (D. Cearley, J. Fenn, and D. Plummer). 2005.
―Gartner’s Positions on the Five Hottest IT Topics and
Trends
in
2005.‖
http://www.gartner.com/DisplayDocument?id=480912.
Booch, Grady. 2006. Blog for March 2006, ―SOA Best
Practices‖.
http://www.booch.com/architecture/blog.jsp?archive=20
06-03.html.
W. Roshen. SOA-Based Enterprise Integration: A Stepby-Step Guide to Services-Based Application
Integration. McGraw-Hill, 2009
Hewitt, E. Java SOA Cookbook. O'Reilly Media, 2009.
P. C. Brown. Implementing SOA: Total Architecture in
Practice. Addison Wesley Professional, 2008.
M. Rosen, B. Lublinsky, K. T. Smith, M. J. Balcer.
Applied SOA: Service-Oriented Architecture and Design
Strategies. WileyPublishing, 2008
Booch and Kruchten. The Rational Unified Process —
An Introduction. Addison-Wesley,1999.
M.H. van Emden. Object-oriented programming as the
end of
history in programming languages.
[13]
[14]
[15]
[16]
[17]
Communications, Computers and Signal Processing,
1997. '10 Years PACRIM 1987-1997 - Networking the
Pacific Rim'. 1997 IEEE Pacific Rim Conference on.
D. Woods, T. Mattern. Enterprise SOA: designing IT for
business innovation. O’Reilly, 2006.
Takahashi, Tadao; Liesenberg, Hans K.E.; Xavier,
Daniel T. Programação orientada a objetos: uma visão
integrada do paradigma de objetos. São Paulo: IMEUSP, 1990.
Goldberg, Adele e D Robson, Smalltalk-80 The
Language and its Implementation, Addison-Wesley,
Reading, MA, 1983
Digitalk, Inc. Smalltalk/V 286 Tutorial and
Programming Handbook e Smalltalk /V Windows
Tutorial and Programming Handbook, Digitalk, Los
Angeles, 1988 e 1992.
Coad, Peter; Yourdon, Edward. Análise baseada em
objetos. Rio de Janeiro: Campus, 1992.