ARQUITETURA

DE SISTEMAS

Pedro Henrique Chagas Freitas

Arquitetura orientada
a serviços
Objetivos de aprendizagem
Ao final deste texto, você deve apresentar os seguintes aprendizados:

 Definir os fundamentos da arquitetura orientada a serviços.

 Discutir como os serviços são projetados, implementados e implantados.
 Introduzir o desenvolvimento de serviços web.

Introdução
Hoje, as grandes corporações pensam a tecnologia como um meio de
prover ganhos para os seus respectivos negócios. Nesse contexto, um dos
principais desafios está na integração entre diferentes tecnologias, com
diferentes regras de negócio em diferentes plataformas. Pensando nisso, foi
criada a arquitetura orientada a serviços (ou SOA, do inglês service-oriented
architecture), que atua, por exemplo, no cenário das aplicações corporativas,
com foco em prover serviços fracamente acoplados e coesos. Esses serviços
visam a substituir, por exemplo, diversos tipos de arquiteturas fortemente
acopladas, que não se comunicam entre si e, por sua vez, geram baixo
nível de coesão — ou seja, redundâncias e defeitos na implantação das
funcionalidades esperadas, conforme leciona Mendes (2002).
Neste capítulo, você vai estudar os fundamentos para a elaboração
da SOA a partir da modelagem e do desenvolvimento orientado a ser-
viços. Você vai analisar o projeto, a implementação e a implantação de
serviços e vai verificar a utilização do paradigma orientado a serviços no
desenvolvimento de serviços web.

Fundamentos da arquitetura orientada a serviços

Para tratarmos dos fundamentos da SOA, bem como das definições que per-
meiam a respectiva temática, precisamos compreender como surgiu o para-
2 Arquitetura orientada a serviços

digma arquitetural orientado a serviços. Antes de mais nada, o paradigma

arquitetural orientado a serviços é uma arquitetura, ou seja, um modelo, um
desenho ou uma forma de se compreender funcionalidades computacionais
— que, na SOA, são chamados de serviços.
Pode-se também adotar a arquitetura orientada a objetos — paradigma
OO (orientação a objetos) —, por exemplo, pela qual, em vez de modelar-
mos serviços, estaríamos modelando objetos. Mas a pergunta é: por que
modelamos objetos ou serviços? A resposta é simples. Veja bem: no nosso
dia a dia, precisamos realizar representações daquilo que existe no mundo
real — como um carro, uma bola, um quadro, uma pessoa, um lápis, uma
televisão, etc. —, o que também ocorre no universo computacional, conforme
apontam Pressman e Maxim (2016). Logo, nos anos 1980, pensou-se em
modelar essas representações do mundo real como objetos; nasceu, então,
o paradigma orientado a objetos. No paradigma orientado a objetos, tem-
-se os métodos, para executar as funções desses objetos, e as classes, para
orquestrar categorias de objetos.
Com o passar dos anos, o seguinte entendimento começou a se estabelecer:
objetos (casa, escola, pessoa, bola, etc.) são representações do mundo real,
mas não são eles que nos entregam valor enquanto funcionalidades. Assim,
concluiu-se que as funcionalidades computacionais desejadas no projeto,
na implementação e na implantação dos software eram os serviços, ou seja,
aquilo que, de fato, entrega valor para o cliente. Dessa forma, teve início um
movimento para modelar os serviços oferecidos pelo software, o que, por sua
vez, fez nascer a SOA.

Em linhas gerais, a SOA é um paradigma que trabalha com recursos distribuídos,

orientados como serviços. Temos, então, as aplicações e suas respectivas fun-
cionalidades. Essas funcionalidades são projetadas como serviços fracamente
acoplados — ou seja, em SOA, trabalhamos com o conceito de independência
entre os serviços. Logo, a SOA serve para modelar e implantar funcionalidades
em formato de serviços.
 Arquitetura orientada a serviços 3

A razão fundamental pela qual a SOA se tornou um passo significativo na

evolução tecnológica foi a mudança de paradigma acarretada. Ou seja, tivemos
um momento para pensar de forma estruturada (paradigma estruturado), depois
de forma orientada a objetos (paradigma orientado a objetos); hoje, deve-se
pensar de forma orientada a serviços. Um exemplo disso é o surgimento de
conceitos como a cloud computing, com os seus diferentes modelos: software
orientado a serviços (SaaS), plataforma orientada a serviços (PaaS) e infra-
estrutura orientada a serviços (IaaS).

Mas, afinal de contas, por que precisamos definir uma SOA? Essa é uma das perguntas
que começam a surgir quando trabalhamos com sistemas distribuídos, que se comu-
nicam com outros sistemas distribuídos, em escala mundial, por meio da internet,
conforme leciona Mendes (2002). Como vimos, a orientação a serviços consiste no
acoplamento de serviços diferentes, com implementações diversas, compondo, assim,
sistemas fracamente acoplados, nos quais rapidamente seria possível adicionar serviços
ou retirar serviços, garantindo a coesão dos mesmos.
Tal atributo, dentro de outros paradigmas, poderia ser caótico. Imagine, por
exemplo, uma classe que compartilha um método com diferentes classes e que,
agora, precisa prover uma nova funcionalidade, com variáveis que não existiam
naquele método quando ele foi criado. Com o paradigma orientado a serviços, as
modificações posteriores à criação dos serviços são mais coesas, exatamente por-
que a abstração ocorre a nível de serviço, ou seja, no nível da funcionalidade que
é entregue. Assim, os serviços podem ser mais facilmente modificados caso surjam
novas demandas.

Antes da SOA, era normal que, conforme as demandas apareciam, a área

de TI se portasse de forma reativa, o que gerava um forte acoplamento (Fi-
gura 1). Assim, toda vez que algo novo surgia, um novo desenho arquitetural
era criado; no fim, observava-se diversos problemas de interoperabilidade
e integração.
4 Arquitetura orientada a serviços

Figura 1. Forte acoplamento antes do surgimento da SOA.

Talvez você esteja pensando: “Por que não colocamos tudo orientado
a serviços? Vamos modelar orientado a serviços e tudo será melhor!”. Por
isso, é importante lembrar: a SOA é um paradigma, e não é possível, do dia
para a noite, colocar tudo o que temos de desenvolvimento de software em
orientação a serviços. Isso ocorre por dois motivos em especial, conforme
aponta Sommerville (2007):

1. a SOA é cara, porque pressupõe mudar a forma de modelar algo que

já está pronto;
2. nem sempre vale à pena propor uma nova arquitetura para algo que já
está em pleno funcionamento.

Projeto, implementação e implantação

de serviços
A palavra-chave para tratar do projeto, da implementação e da implantação
de serviços, por meio da SOA, é o barramento de serviço, também chamado
service bus ou enterprise service bus (ESB). Como mostra a Figura 2, o
ESB é o coração da SOA; por meio dele, podemos prover comunicação entre
diversos sistemas, plataformas, aplicações e, inclusive, entre tecnologias
diferentes.
 Arquitetura orientada a serviços 5

Figura 2. O barramento de serviço é o coração da SOA.

A comunicação em um ESB é realizada principalmente por meio de XML

(extensible markup language) e web services. O ESB representa um ponto
centralizador da integração entre as aplicações que necessitam comunicar-se.
Logo, a primeira etapa do projeto dos serviços é a constituição do barramento
de serviço, conforme lecionam Pressman e Maxim (2016).
Suponha que um data warehouse (DW) precise acessar um dado em um
sistema departamental, para prover um serviço. Então, em vez de consultar
o dado diretamente (consultar um CPF, por exemplo), via componente ou
base de dados, a requisição da consulta ocorre diretamente ao ESB, e este se
comunica com a base, que retorna o dado esperado (p. ex., o CPF). Logo, o
DW é simplesmente um consumidor de um serviço de consulta a uma base de
dados departamental, via ESB. Ou seja, é como se o dado fosse encapsulado
para ser acessado pelos serviços disponibilizados no barramento.

Para atribuir segurança no contexto de comunicação, utiliza-se a XML encryption, a fim

de criptografar partes de um documento, restringindo, assim, o acesso aos serviços,
conforme aponta Mendes (2002).

Na implementação, precisamos orquestrar os serviços; ou seja, os ser-

viços, assim como os requisitos, são mapeados e modelados, a fim de
serem incluídos no barramento de serviço. Dessa forma, conforme leciona
6 Arquitetura orientada a serviços

Mendes (2002), coordenamos o acesso e o consumo dos serviços por meio

do ESB. Essa coordenação é chamada de governança SOA, conforme
mostrado na Figura 3.

Figura 3. A governança SOA consiste na coordenação de serviços por meio do barramento

de serviços.

Então, temos o barramento (ESB) orquestrando os serviços por meio

da linguagem de comunicação entre serviços, sendo a linguagem mais
difundida a business process execution language (BPEL). A utilização
da BPEL muitas vezes ocorre pela utilização da notação BPM (business
process management), que modela os serviços; em outros casos, utiliza-se a
unified modeling language (UML) para modelar objetos, conforme lecionam
Pressman e Maxim (2016). Temos, então, após a modelagem com o BPM e
a utilização da orquestração por meio da BPEL, a implantação da SOA. A
estrutura implantada remonta à seguinte lógica: encontra, consolida e regis-
tra (Figura 4). Ou seja, o provedor de serviço publica os serviços por meio
do ESB, gerando registros no padrão universal, discovery and integration
(UDDI), com a especificação web service description language (WSDL),
conforme leciona Sommerville (2007).
O registro dos serviços implantados ocorre como uma base de dados
de informação. Quando um sistema, por exemplo, deseja consumir algum
serviço, ele busca no registro do serviço (UDDI), a fim de verificar a espe-
cificação do serviço e localizá-lo. Essa comunicação, por sua vez, ocorre por
meio do protocolo SOAP (simple object access protocol) ou do protocolo
 Arquitetura orientada a serviços 7

REST (representational state transfer, abordado na próxima seção). Logo,

temos três colunas principais na SOA:

 UDDI, padrão responsável pelo descobrimento, que define as infor-

mações sobre os serviços;
 WSDL, responsável pela interface que representa os serviços;
 SOAP, protocolo responsável pela comunicação e troca de dados.

Veja na Figura 4.

Figura 4. Lógica da SOA.

Introdução ao desenvolvimento de serviços web

Para tratarmos sobre o desenvolvimento de serviços web, precisamos tratar
do REST (do inglês representation state transfer, ou transferência de estado
representacional). O REST é o modelo de desenvolvimento de serviços
para web mais utilizado e apresenta como grande vantagem a simplicidade.
Ou seja, no REST, o consumo e o provimento dos serviços por meio da
web ocorre de maneira rápida e simples, conforme lecionam Pressman e
Maxim (2016).
8 Arquitetura orientada a serviços

O REST surgiu da dissertação de doutorado de Roy Fielding, intitulada Architectural styles

and the design of network-based software architectures. Nela, Fielding afirma que os estilos
arquiteturais web são utilizados pelos engenheiros de software para projetar sistemas
complexos. Fielding aponta, dentre esses estilos, os padrões que são estruturados de
maneira a fortalecer uma determinada arquitetura de serviços web — os padrões REST.

Nesse sentido, podemos prever que vão existir “n” tipos de sistemas, que
terão “x” tipos de níveis de abstração, cada um com a sua própria arquitetura
e com diferentes níveis de complexidade, conforme aponta Mendes (2002).
Temos, então, os chamados estilos de arquiteturas de serviços web, cujo
objetivo é abstrair descrições de diversos aspectos que constituem funcionali-
dades web. Desses estilos, o estilo denominado arquitetura cliente–servidor
é o mais utilizado na web para trafegar dados (Figura 5).

Figura 5. Estilo arquitetural cliente–servidor.

No estilo arquitetural cliente–servidor, temos a composição de um servidor

que vai fornecer serviços por meio de conexões com os clientes, ou com o cliente
(arquitetura cliente–servidor dedicada). Do outro lado, temos o cliente, que é
responsável por definir quais serviços vai requisitar ao servidor. Temos, então,
na web, o servidor aguardando a requisição do cliente, podendo, obviamente,
servir a mais de um cliente. Logo, temos a separação de responsabilidades
entre servidor e cliente. De forma bem simples, pode-se dizer que o servidor
é responsável por processar a requisição e que o cliente é responsável por
processar o que foi requerido, conforme leciona Sommerville (2007).
 Arquitetura orientada a serviços 9

Segundo Pressman e Maxim (2016), o REST é um estilo arquitetural híbrido que surgiu
da representação de sistemas de hipermídia distribuídos, derivados de outros modelos
arquiteturais.

Para compreender o que é REST e como ele implementa de forma simples

os serviços web, é necessário avaliar o modelo cliente–servidor e a sua razão
de existir. Perceba que a abstração de camadas serve para trazer para cada
camada uma função, conforme sintetiza a Figura 6.

Figura 6. Síntese do modelo cliente–servidor.

Apesar de o REST ser o modelo de desenvolvimento web por serviço mais

empregado, existem outros tipos de modelos de serviços para desenvolvimento
web além do REST. Entre eles, podemos destacar:

 modelo de desenvolvimento arquitetural via cache;

 modelo de desenvolvimento cliente–servidor sem estado;
 modelo arquitetural cliente com cache–servidor sem estado.
10 Arquitetura orientada a serviços

Quando trabalhamos com o modelo cliente–servidor e com a distribuição

em camadas, temos a possibilidade de desenvolver a separação de responsa-
bilidades entre os componentes. É exatamente isso que ocorre no REST, o
que faz com que o desenvolvimento web REST tenha condição de suportar
requerimentos de aplicações de múltiplos domínios organizacionais na escala
da internet.
Assim, em REST, as comunicações web não devem depender dos esta-
dos controlados pelo servidor; dessa evolução de pensamento, nasce o estilo
cliente–servidor sem estado. E por que isso? Porque a ideia é fazer com que
cada requisição feita pelo cliente sempre — lembre-se, sempre — tenha todos
os atributos para que ela possa ser processada pelo servidor. Assim, temos a
certeza de que toda a informação, ou serviço, será conhecida somente pelo
cliente, conforme expõe Mendes (2002).
Vamos analisar, então, o modelo cache + cliente — ou seja, vamos unir
o modelo de arquitetura cache e o modelo cliente–servidor sem estado, para
implementação de serviços web. O que se observa na união desses dois modelos
de desenvolvimento de serviços web é a melhora na eficiência da comunicação
entre cliente e servidor. O REST busca unir características do modelo arqui-
tetural via cache, de forma a incorporar o estilo cliente–servidor sem estado.
Logo, a união dessas características faz com que exista a necessidade de
marcação explícita de uma resposta, relacionada ao fato de esta ser ou não
passível de cache. Por exemplo: se for possível que a resposta do serviço seja
passível de cache, podemos garantir ao cliente que ele poderá reusar essa
resposta futuramente, conforme lecionam Pressman e Maxim (2016). Temos,
então, a característica de que o cliente pode inserir em tempo de execução as
funcionalidades que ele desejar, por meio de scripts ou applets.
É daí que surge um conceito muito familiar, conhecido como web ser-
vices. A maioria das aplicações que são voltadas para a utilização de REST
são orientadas a serviços; ou seja, a ideia é encapsular serviços por meio da
web, em camadas, e gerar sua comunicação por meio do HTTP (hypertext
transfer protocol, ou protocolo de transferência de hipertexto), conforme
expõe Sommerville (2007).
O REST também é muito utilizado para o desenvolvimento de serviços web
trabalhando de maneira stateless (sem estado). A implementação dos serviços
web implementados com REST são conhecidos como RESTful web services.
Os serviços no REST, por sua vez, são identificados pelo seu identificador
uniforme de recursos (URI, do inglês uniform resource identifier). Por fim,
entre outras, as principais operações dos métodos HTTP para o desenvolvi-
mento de serviços web por meio de REST são as descritas na Figura 7.
 Arquitetura orientada a serviços 11

Figura 7. Principais operações dos métodos HTTP para o desenvolvimento de serviços

web por meio de REST.

MENDES, A. Arquitetura de software. Rio de Janeiro: Editora Campus, 2002.

PRESSMAN, R. S.; MAXIM, B. R. Engenharia de software: uma abordagem profissional. 8.
ed. Porto Alegre: Bookman, 2016.
SOMMERVILLE, I. Engenharia de software. 8. ed. São Paulo: Pearson, 2007.