Arquitetura_Orientada_Servico - SOA

Prévia do material em texto

Arquitetura Orientada
a Serviço
Créditos
Centro Universitário Senac São Paulo – Educação Superior a Distância
Diretor Regional 
Luiz Francisco de Assis Salgado
Superintendente Universitário 
e de Desenvolvimento 
Luiz Carlos Dourado
Reitor 
Sidney Zaganin Latorre
Diretor de Graduação 
Eduardo Mazzaferro Ehlers
Diretor de Pós-Graduação e Extensão 
Daniel Garcia Correa
Gerentes de Desenvolvimento 
Claudio Luiz de Souza Silva 
Luciana Bon Duarte 
Roland Anton Zottele 
Sandra Regina Mattos Abreu de Freitas
Coordenadora de Desenvolvimento 
Tecnologias Aplicadas à Educação 
Regina Helena Ribeiro
Coordenador de Operação 
Educação a Distância 
Alcir Vilela Junior
Professores Autores 
Mikiko Ishida 
Éder Frances Oliveira 
Vinicius Moll
Revisor Técnico 
Marcelo José Szewczyk
Técnico de Desenvolvimento 
Ozeas Vieira
Coordenadoras Pedagógicas 
Ariádiny Carolina Brasileiro Silva 
Izabella Saadi Cerutti Leal Reis 
Nivia Pereira Maseri de Moraes 
Otacília da Paz Pereira
Equipe de Design Educacional 
Alexsandra Cristiane Santos da Silva 
Ana Claudia Neif Sanches Yasuraoka 
Angélica Lúcia Kanô 
Anny Frida Silva Paula 
Cristina Yurie Takahashi 
Diogo Maxwell Santos Felizardo 
Flaviana Neri 
Francisco Shoiti Tanaka 
Gizele Laranjeira de Oliveira Sepulvida 
Hágara Rosa da Cunha Araújo 
Janandrea Nelci do Espirito Santo 
Jackeline Duarte Kodaira 
João Francisco Correia de Souza 
Juliana Quitério Lopez Salvaia 
Jussara Cristina Cubbo 
Kamila Harumi Sakurai Simões 
Katya Martinez Almeida 
Lilian Brito Santos 
Luciana Marcheze Miguel 
Mariana Valeria Gulin Melcon 
Mônica Maria Penalber de Menezes 
Mônica Rodrigues dos Santos 
Nathália Barros de Souza Santos 
Rivia Lima Garcia 
Sueli Brianezi Carvalho 
Thiago Martins Navarro 
Wallace Roberto Bernardo
Equipe de Qualidade 
Ana Paula Pigossi Papalia 
Josivaldo Petronilo da Silva 
Katia Aparecida Nascimento Passos
Coordenador Multimídia e Audiovisual 
Ricardo Regis Untem
Equipe de Design Audiovisual 
Adriana Mitsue Matsuda 
Caio Souza Santos 
Camila Lazaresko Madrid 
Carlos Eduardo Toshiaki Kokubo 
Christian Ratajczyk Puig 
Danilo Dos Santos Netto 
Hugo Naoto Takizawa Ferreira 
Inácio de Assis Bento Nehme 
Karina de Morais Vaz Bonna 
Marcela Burgarelli Corrente 
Marcio Rodrigo dos Reis 
Renan Ferreira Alves 
Renata Mendes Ribeiro 
Thalita de Cassia Mendasoli Gavetti 
Thamires Lopes de Castro 
Vandré Luiz dos Santos 
Victor Giriotas Marçon 
William Mordoch
Equipe de Design Multimídia 
Alexandre Lemes da Silva 
Cristiane Marinho de Souza 
Emília Correa Abreu 
Fernando Eduardo Castro da Silva 
Mayra Aoki Aniya 
Michel Iuiti Navarro Moreno 
Renan Carlos Nunes De Souza 
Rodrigo Benites Gonçalves da Silva 
Wagner Ferri
Arquitetura Orientada a Serviço
Aula 01
Introdução à SOA e apresentação dos principais conceitos
Objetivos Específicos
• Apresentar o problema atual das empresas no que tange à integração entre 
sistemas (troca de arquivo, base de dados compartilhada, entre outros).
Introdução
1 Introdução à SOA
2 Histórico
3 Fato: existência de silos e o impacto no negócio
4 Integração de sistemas
Considerações finais
Referências
Temas
Mikiko Ishida
Professor Autor
Senac São Paulo - Todos os Direitos Reservados
Arquitetura Orientada a Serviço
2
Introdução
Nesta aula, vamos introduzir os principais conceitos da Arquitetura Orientada a Serviço, 
do termo em inglês Service-Oriented Architecture (SOA), e conhecer alguns fatos que 
motivaram o seu surgimento. 
Para ajudar a entender os motivadores da evolução das tecnologias de integração de 
sistemas, uma breve passagem histórica é apresentada para explicar como o desenvolvimento 
do mercado e os seus respectivos impactos impulsionaram as mudanças nas empresas, 
apoiando-se mais e mais na Tecnologia da Informação.
1 Introdução à SOA
Antes de falarmos sobre SOA, vamos fazer uma analogia com uma cidade. Cada empresa 
que aparece na Figura 1, “Uma cidade com empresas e serviços”, é orientada a um tipo 
de serviço (especialização) que pode ser utilizado por vários consumidores. Por exemplo, 
lavanderias, postos de combustível, restaurantes, cabeleireiros, correios, escolas, hotéis, 
escritórios de contabilidade, imobiliárias etc. 
Vamos pegar três empresas que precisam dos serviços terceirizados de uma lavanderia 
porque seus negócios têm outros objetivos, como um restaurante, um cabeleireiro e um 
hotel. Esta necessidade de negócio (lavar roupas) demanda uma integração entre cada uma 
dessas empresas com a lavanderia. A integração é viabilizada pelas ruas que interligam os 
estabelecimentos e pelos veículos que carregam as roupas (dados). O serviço de lavagem 
de roupas é reusável, pois esses clientes podem voltar a utilizá-lo, assim como outros 
estabelecimentos podem reusar o mesmo serviço. Coletivamente, essas empresas formam 
uma comunidade de negócios, na qual é esperado que o consumidor não seja servido por 
uma única empresa que ofereça todos os tipos de serviços.
Figura 1 – Uma cidade com empresas de serviços
Senac São Paulo - Todos os Direitos Reservados
Arquitetura Orientada a Serviço
3
Existem quatro aspectos fundamentais na arquitetura orientada a serviço que agregam 
valor ao negócio.
1.1 Serviço
É importante entender que estamos falando sob a ótica de processo de negócio, portanto, 
não pense no contexto de software ou de TI – Tecnologia da Informação. Pense sobre o que 
uma empresa faz no seu dia a dia e “quebre” os processos de negócio em tarefas de negócio 
repetíveis ou componentes. Um serviço é autodescritivo e localizável, atende a requisitos 
de qualidade de serviço e pode ser gerenciado pela governança. Por exemplo, serviço de 
verificação de crédito ou serviço de criação de uma conta nova. Podemos fazer uma analogia 
com aquele brinquedo de peças ou de blocos montáveis, que permite criar e montar blocos 
maiores ou até uma estrutura completa.
Figura 2 – Peças e blocos de montagem
1.2 Orientação a serviço
Assim como serviço foi definido e comparado a blocos montáveis, orientação a serviço é 
uma abordagem para integrar uma empresa como serviços interconectados. Ela permite aos 
aplicativos chamar o comportamento de outros aplicativos como serviço, com o objetivo de 
gerar resultados ao negócio.
1.3 A arquitetura orientada a serviço
É um estilo de arquitetura de TI que usa os princípios da orientação a serviço1 para 
estreitar a relação entre a empresa e os sistemas de informação que suportam o seu negócio.
1 Orientação a serviço é uma abordagem para integrar uma empresa como serviços interconectados, em que uma aplicação pode chamar uma 
função de outra aplicação como serviço.
Senac São Paulo - Todos os Direitos Reservados
Arquitetura Orientada a Serviço
4
Seu maior objetivo é alcançar a possibilidade de conectar uma ampla variedade de 
sistemas sem a necessidade de descartar sistemas existentes.
1.4 Aplicação composta
Aplicações compostas são os serviços em execução de fato que foram montados ou 
construídos e “amarrados juntos”, ou seja, integrados para apoiar o que a empresa faz. A SOA 
ajuda a tornar a criação de aplicativos e os ajustes de aplicações compostas mais rápidos e 
mais fáceis.
Porém, para que este modelo funcione de forma a trazer resultados ao negócio, deve-se 
evitar o alto nível de interdependência entre os serviços individuais, utilizando as boas práticas 
que a orientação a serviço nos traz. O serviço deve ter uma atividade bem definida e baixo nível 
de acoplamento na interação com outro serviço. Desta forma, os serviços individuais podem se 
autogovernar e crescer em volume, de forma relativamente independente um do outro.
As arquiteturas antigas, antes do SOA, não suportam a flexibilidade e a agilidade que a 
demanda de negócio atualmente precisa. Geralmente as aplicações eram desenvolvidas de 
formas monolíticas, com todas as unidades lógicas de serviço em um único bloco.
2 Histórico
A economia mundial e a tecnologia vêm se transformando de uma forma cada vez mais 
rápida, ajudando no desenvolvimento de ambas.Porém, esse fenômeno também causa pressão 
nas empresas para que se adaptem, tornem-se mais produtivas e mais ágeis. A necessidade de 
se tornar mais produtivo e competitivo girava principalmente em torno do produto ofertado 
ao cliente. Agora, o foco vem mudando para o serviço que o cliente espera receber.
Os investimentos das empresas têm sido dedicado à modernização dos equipamentos 
produtivos (instrumentação) e também à revisão e automação de processos de negócio para 
que consigam atender a essas mudanças de mercado com mais resiliência. Tudo isso seria muito 
mais difícil e lento se não fosse a TI (Tecnologia da Informação). Quanto mais informatizada a 
empresa é (com base em processos, metodologia, padrões abertos e governança), mais ágil 
e flexível ela se torna para reagir aos movimentos do mercado e manter a competitividade e 
o crescimento.
Portanto, sob a ótica de TI, foi necessário adotar novas técnicas de integração de sistemas, 
novos modelos para organizar as informações, novos processos e estilos de arquitetura, novas 
formas de desenvolver aplicações, chegando a mudar as necessidades de implementação 
dos aplicativos (que neste novo contexto representam serviços de negócio), do tradicional 
ambiente centralizado para o distribuído de fato.
Senac São Paulo - Todos os Direitos Reservados
Arquitetura Orientada a Serviço
5
3 Fato: existência de silos e o impacto no negócio
Há décadas, cada departamento de grandes empresas tem desenvolvido seus próprios 
sistemas de aplicações e geralmente com suas próprias bases de dados. Quando a empresa 
precisa reunir vários departamentos para tomar uma decisão de negócio, descobre que as 
definições de dados, por exemplo, que cada departamento utilizou são diferentes. 
Ex.: o que é cliente, nomes de produto etc. Um cliente pode ter várias contas criadas, 
mas não estão associadas entre si. A inconsistência dos dados e a falta de precisão das 
informações impedem que a decisão de negócio seja tomada.
Apesar dos departamentos terem resolvido eficientemente os problemas com seus 
sistemas, mesmo que de grande complexidade, nem sempre partilham das mesmas 
prioridades, objetivos e tipo de tecnologia que os outros departamentos.
Existem vários tipos de silos2 que acabam limitando a atuação das empresas no 
atingimento de seus objetivos de negócio.
a. Os silos organizacionais causam atritos entre as diversas prioridades de atendimento;
b. Já os silos de informação restringem a visibilidade dos dados necessários para a 
excelência do serviço;
c. Os silos de processo impedem a integração inerente às melhores práticas;
d. Outro tipo de silo é o de tecnologia, que impede a integração de dados necessária, 
para conseguir uma orientação de serviço, e a automação necessária, para direcionar 
a melhoria de qualidade e custos baixos. Aqui entra a necessidade de adotar as 
tecnologias adequadas para integração corporativa orientada a serviço e a viabilização 
da automação dos processos com recursos de software.
Figura 3 – Silos organizacionais
2 Silo, neste contexto, quer dizer isolado, sem comunicação com o silo vizinho. O termo foi inspirado nos silos agrícolas, que geralmente são 
construções cilíndricas fechadas, criadas para armazenar a produção agrícola, como grandes celeiros fechados e isolados.
Senac São Paulo - Todos os Direitos Reservados
Arquitetura Orientada a Serviço
6
Silos são verticais por natureza, mas servir o cliente requer uma visão horizontal. Uma 
das principais estratégias para tornar a empresa mais ágil, flexível, resiliente e eficaz é 
transpor a barreira dos silos para que a empresa possa se relacionar com seus clientes de 
forma personalizada e efetiva.
A adesão às melhores práticas baseada na arquitetura orientada a serviço possibilita a 
integração dos silos de informação, processos, pessoas e tecnologia. Portanto, a área de TI 
consegue entregar serviços de valor às linhas de negócio, com qualidade e confiabilidade.
4 Integração de sistemas
Aplicações interessantes raramente ficam isoladas (HOHPE; WOOLF, 2005, p. XXIX). 
Quando uma aplicação deve fazer interface com outra por uma necessidade de negócio, 
requer uma comunicação entre as duas, ou seja, uma integração. Toda integração precisa 
lidar com alguns desafios como: redes não confiáveis ou lentas, aplicações que são diferentes 
na linguagem, formato de dados ou plataforma onde executa e mudanças que são inevitáveis.
A integração da empresa não é uma tarefa simples. Por definição, a integração corporativa 
precisa lidar com vários aplicativos rodando em múltiplas plataformas e em diferentes 
localidades. 
4.1 Os desafios da integração de sistemas
Com a necessidade crescente de integração de vários e diferentes sistemas surgiram 
também vários problemas técnicos e questões com que os analistas de sistema e 
desenvolvedores tiverem de se deparar, como: 
Figura 4 - Desafios da integração de sistemas
Senac São Paulo - Todos os Direitos Reservados
Arquitetura Orientada a Serviço
7
4.1.1 Problemas da integração ponto a ponto
Era comum construir integrações para atender às necessidade de negócio, sem 
planejamento. Consequentemente, o crescimento desordenado de integrações 
descentralizadas criou uma rede de conexões entre os vários sistemas da empresa. A troca 
de informação era feita apenas entre dois sistemas, isto é, independentes e separados das 
demais integrações. Qual seria o impacto se houver a necessidade de mudar a estrutura do 
registro de contato dos clientes, acrescentando no campo endereço o Twitter, LinkedIn e/ou 
Facebook3. Como saber o impacto desta mudança? Este modelo de integração ponto a ponto 
dificulta a implementação de mudanças nos sistemas, formatos de registros e conteúdo das 
mensagens trocadas entre as aplicações. 
Figura 5– Conexões ponto-a-ponto entre as aplicações
Essas integrações surgiram para atender demandas pontuais e, ao longo do tempo, 
o volume aumentou tanto que a arquitetura ficou confusa e muito difícil de entender. 
Imagina a dificuldade para encontrar uma integração que precisa ser atualizada? Por 
isso, o foco da imagem são as linhas vermelhas que podem aumentar de quantidade 
rapidamente e trazer dificuldades em termos de flexibilidade e agilidade para atender 
às novas demandas das áreas de negócio.
3 Twitter, LinkedIn e Facebook são sistemas de colaboração do tipo redes sociais muito populares hoje em dia.
Senac São Paulo - Todos os Direitos Reservados
Arquitetura Orientada a Serviço
8
4.1.2 Desafios além dos problemas técnicos
Muitos fornecedores de software oferecem soluções de integração com funcionalidades 
para apoiar a integração entre plataformas, linguagens de programação, como também a 
habilidade de se integrar com vários pacotes de aplicação mais populares. Porém, os requisitos 
técnicos de infraestrutura para resolver esses desafios formam uma parte menor dentre as 
complexidades em torno da integração. 
a. Os verdadeiros desafios da integração ultrapassam a fronteira entre os problemas 
técnicos e de negócio.
b. A integração corporativa requer mudanças significativas nas políticas da empresa.
c. A amplitude do escopo da integração geralmente traz implicações de longo alcance 
ao negócio.
d. O controle limitado dos desenvolvedores sobre as aplicações participantes da 
integração, legadas ou pacote, muitas vezes não consegue desenvolver diretamente 
no código, levando-os a criar soluções de contorno.
e. A falta de utilização de padrões para integração pelas soluções que implementam a 
interoperabilidade entre os sistemas.
4.2 Características da integração
Os componentes da integração que participam de uma arquitetura de integração são:
a. Sistemas – as aplicações ou sistemas que trocarão informações entre si;
b. Dados – as informações que vão trafegar entre as aplicações ou sistemas;
c. Interface – formato de envio e recebimento das informações entre as aplicações ou 
sistemas; 
d. Comunicação – modalidade da comunicação na troca de informações entre as 
aplicaçõesou sistemas.
Se as necessidades de integração fossem semelhantes, haveria apenas um estilo de 
integração. Existe mais de uma abordagem e os principais tipos de integração são:
a. Transferência de arquivo – cada aplicação que precisa compartilhar alguns dados 
cria um arquivo para ser consumido por outra aplicação e também consome arquivos 
gerados por outras aplicações;
b. Base de dados compartilhada – as aplicações armazenam os dados que querem 
compartilhar em uma base de dados comum;
Senac São Paulo - Todos os Direitos Reservados
Arquitetura Orientada a Serviço
9
c. Remote Procedure Invocation4 – cada aplicação expõe alguns de seus 
procedimentos, para que possam ser chamados remotamente, e também chamam 
procedimentos expostos por outros sistemas para executar a lógica e a troca de 
informações;
d. Mensageria – uma aplicação se conecta a um sistema de mensagens (ou 
“mensageria”, termo comumente utilizado que veio do inglês “messaging”) comum 
para trocar informações e mensagens contendo instruções sobre o que deve ser feito 
com os dados enviados.
4.3 Soluções de integração
O alto volume de integrações criadas para atender à demanda dos negócios transformou 
a arquitetura de integração em “espaguete” (termo utilizado para expressar a quantidade 
muito alta de integrações ponto a ponto entre sistemas).
O surgimento da internet na década de 1990 mostrou o poder dos padrões 
abertos quando aplicados a arquiteturas cliente-servidor. Isso criou as condições para o 
desenvolvimento dos padrões Web Services.
Portanto, as soluções de integração chegaram para fundamentar a arquitetura orientada 
a serviços com: padrões (XML); componentes de software (Web Services) e a evolução de 
modelos de arquitetura (ponto a ponto; Hub-Spoke e Pipeline).
4.3.1 Tecnologia
Como forma de lidar com os problemas de integração, começaram a surgir no mercado 
novos padrões e tecnologias inovadoras. Dentro das mais importantes, podemos referir: 
• XML – vem do termo em inglês eXtensible Markup Language. Esta tecnologia foi 
criada pela W3C (World Wide Web Consortium). O XML começou a se popularizar 
no fim da década de 1990 durante o movimento do eBusiness, que demandou o uso 
de linguagens de escrita (script) no lado do servidor para viabilizar os negócios das 
empresas via internet. O XML permite anexar significado e contexto para qualquer 
parte da informação transmitida através de protocolos de internet. Apresenta dados 
como arquivos de texto simples para facilitar a leitura da informação. Este padrão 
viabilizou a tão desejada interoperabilidade aberta.
4 Remote Procedure Invocation é uma tecnologia conhecida como chamada remota de procedimento, que permite a uma aplicação chamar e 
executar um procedimento em outro sistema.
Senac São Paulo - Todos os Direitos Reservados
Arquitetura Orientada a Serviço
10
• WebServices – é um componente de software criado com uma interface pública 
que permite às aplicações enviar e receber dados em formato XML. Tecnologia 
que permite que diferentes aplicações possam se comunicar entre si usando os 
protocolos HTTP e HTPPS, ainda que em plataformas distintas ou desenvolvidas em 
linguagens diferentes. Permite ainda incorporar dentro das mensagens protocolos de 
autenticação, autorização e encriptação. 
4.3.2 Arquiteturas de integração
Até o momento, falamos sobre a arquitetura ponto a ponto, que traz limitações para as 
empresas. Este cenário ainda é simples. É possível entender as integrações pré-espaguete.
Figura 6 – Arquitetura ponto a ponto
Fonte: Adaptada de Redbooks (2002, p. 11). 
Existem diferentes produtos/arquiteturas que trouxeram inovações relevantes dentro da 
área de integração de sistemas ou EAI (Enterprise Application Integration):
• Arquitetura Hub-Spoke5 – faz uso de um broker ou de um componente que centraliza 
o processamento de mensagens (o Hub, que neste caso seria um centro) e de vários 
adaptadores que se conectam com as diferentes aplicações (Spoke, que seriam as 
terminações). Assim, o broker ficaria responsável pela transformação, segurança e 
roteamento das mensagens para os adaptadores que se conectariam e enviariam as 
mensagens propriamente ditas para as aplicações. Existem ainda hoje várias soluções 
no mercado que cumprem com esta arquitetura de sistemas, a qual demanda alguma 
especialização no desenvolvimento, mas, enquanto solução fechada e integrada, o 
seu uso é relativamente simples. 
5 Hub-spoke é um termo inglês que nasceu inspirado no modelo de distribuição de pacotes em voos americanos para otimizar a logística. Este 
modelo consiste em um aeroporto central (hub) e os voos para outros aeroportos como se fossem raios de uma roda de bicicleta (spoke).
Senac São Paulo - Todos os Direitos Reservados
Arquitetura Orientada a Serviço
11
Figura 7 – Representação gráfica de uma arquitetura Hub-Spoke
Fonte: Adaptada de Redbooks (2002, p. 12). 
• Arquitetura Pipeline ou BUS – esta arquitetura se parece bastante com a anterior 
por seguir as mesmas características. No entanto, possui uma interessante diferença: 
os componentes de transformação e roteamento estão distribuídos também pelos 
adaptadores. Pelo fato de os adaptadores processarem mensagens na mesma 
plataforma da aplicação para a qual foram criados, é possível ter um plano de 
escalabilidade melhor, pois os serviços podem ficar distribuídos entre as plataformas 
participantes do ambiente. Isso evita a necessidade de acrescentar recursos em 
um servidor central. Outra diferença que podemos destacar é o uso de tipos de 
mensagens padronizadas e tecnologias abertas, além dos produtos Hub-Spoke que 
fazem parte desta arquitetura também.
Figura 8 – Arquitetura Pipeline
Fonte: Adaptada de Hohpe e Woolf (2005, p. 54). 
• Arquitetura Orientada a Serviço – esta arquitetura diferencia-se das anteriores 
porque os processos de negócio e as aplicações já não são codificados como estruturas 
complexas de programas, mas são orquestrados através das chamadas de serviço, de 
forma distribuída e independente. As empresas que adotaram a arquitetura orientada 
a serviço há alguns anos observam hoje resultados refletidos em seus negócios, tanto 
na agilidade de resposta ao mercado quanto na flexibilidade para criar novos serviços 
e se adaptar a mudanças que, às vezes, o mercado impõe.
ftp://www.redbooks.ibm.com/redbooks/ITSO%20WebSphere%20Forum/bi/BI07.pdf
Senac São Paulo - Todos os Direitos Reservados
Arquitetura Orientada a Serviço
12
Figura 9 – Arquitetura de Referência SOA
Fonte: The OpenGroup6 (2015). 
Estas tecnologias que exploramos representam algumas soluções que foram incorporadas 
em SOA, mas não as únicas. Na verdade, a SOA pode ser considerada uma evolução natural e 
especializada do mundo de TI na forma de paradigma7.
Considerações finais
Podemos, então, considerar que a arquitetura orientada a serviços surgiu como uma 
solução em resposta aos problemas atuais das empresas. Ela se apresenta mais holística do 
que as abordagens comuns, pois representa um avanço não só tecnológico (reaproveitando 
um conjunto integrado de novas tecnologias), mas também conceitual. Ela é importante para 
que seja possível resolver não só problemas de integração de sistemas, mas, sobretudo, para 
alavancar a dinâmica de negócio das empresas.
Referências
ERL, Thomas. SOA: Princípios de design de serviços. São Paulo: Prentice Hall, 2008.
ERL, Thomas. Service-Oriented Architecture: Concepts, Technology, and Design. Indiana - EUA, 
2005.
6 OpenGroup é um consórcio global que viabiliza o atingimento dos objetivos de negócio através de padrões de TI (especificações de padrões 
abertos).
7 Paradigma pode ser uma abordagem a algo, uma escola de pensamento com relação a algo ou um conjunto combinado de regras aplicadas 
dentro de um limite predefinido. ERL, Thomas. SOA: Princípios de design de serviços. São Paulo: Prentice Hall, 2008. p. 19
Senac São Paulo - Todos os Direitos Reservados
Arquitetura Orientada a Serviço
13
HURWITZ, Judith; BLOOR, Robin; KAUFMAN,Marcia; HALPER, Dra. Fern. Arquitetura Orientada 
a Serviços – SOA para Leigos. Rio de Janeiro, 2009.
HOHPE, Gregor; WOOLF, Bobby. Enterprise Integration Patterns. Boston: Pearson Education 
Inc., 2005.
OPENGROUP: <https://www.opengroup.org/soa/source-book/soa_refarch/services.htm>. 
Acesso em: 15 julho 2015.REDBOOKS. International Technical Support Organization. Using Web 
Services Technology for Enterprise Application Integration: Session BI07. La Hulpe, Belgium: 
IBM International Education Center, 2002. Disponível em: SOA and web services: <https://www.
ibm.com/developerworks/webservices/>. Acesso em: 15 julho 2015.
<ftp://www.redbooks.ibm.com/redbooks/ITSO%20WebSphere%20Forum/bi/BI07.pdf>. 
Acesso em: 25 jul. 2015.
THE OPENGROUP. SOA reference architecture technical standard: services layer. Disponível 
em: <https://www.opengroup.org/soa/source-book/soa_refarch/services.htm>. Acesso em: 15 
jul. 2015.
WOOLF, B. Exploring IBM SOA Technology & Practice: How to Plan, Build and Manage a Service 
Oriented Architecture in the Real World. EUA, 2008. 
https://www.opengroup.org/soa/source-book/soa_refarch/services.htm
https://www.ibm.com/developerworks/webservices/
https://www.ibm.com/developerworks/webservices/
Arquitetura Orientada a Serviço
Aula 02
Utilização de SOA visando à flexibilidade nos negócios 
Objetivos Específicos
• Demonstrar como SOA suporta a flexibilidade nos negócios, garantindo 
menor impacto em alterações de regras de negócio.
Temas
Introdução
1 Orientação a serviços
2 Vantagens da computação orientada a serviços
Considerações finais
Referências
Mikiko Ishida
Professor Autor
Senac São Paulo - Todos os Direitos Reservados
Arquitetura Orientada a Serviço
2
Introdução
Nesta aula vamos começar a entender como podemos viabilizar os benefícios que a 
arquitetura orientada a serviços nos oferece. Esta abordagem é resultado de uma coleção de 
conhecimentos e experiências anteriores que motivaram o surgimento de novos princípios 
de construção (design), além de manter algumas práticas e tecnologias já existentes.
A proposta de SOA é muito interessante, mas podemos perceber que a sua implemen-
tação deve ser algo realizado com base em boas práticas, já identificadas e publicadas pelos 
profissionais mais experientes no mundo todo e que nos ajudam a começar de forma mais 
organizada e não do zero.
Em inglês há uma expressão muito utilizada quando estamos em uma situação como esta, 
ou seja: se quero adotar a arquitetura orientada a serviço, é importante estudar bem, antes 
de começar, porque “não há almoço grátis” (“There’s no free lunch”). Porém, a afirmação de 
Thomas Erl (2008, p. 2), “[...] a chave para se fazer algo com sucesso é entender o que se 
está fazendo”, reflete bem a chave do segredo e vale para qualquer projeto que queremos 
ter sucesso.
O principal objetivo do esforço em utilizar a arquitetura orientada a serviço é produzir 
uma coleção de serviços padronizados e aderentes às necessidades de negócio da empresa. 
A SOA estabelece um modelo de arquitetura que visa a melhorar a agilidade, a flexibilidade, a 
eficácia e a produtividade de uma empresa, e os serviços são os principais viabilizadores dos 
objetivos estratégicos que estão associados à computação orientada a serviços1.
1 Orientação a serviços
A orientação a serviço é um paradigma de construção e integração de soluções de 
software compostas por elementos modulares chamados serviços. O paradigma baseia-se nos 
princípios de orientação a serviços (FUGITA; HIRAMA, 2012, p. 7) que serão descritas a seguir.
Serviço sempre existiu na história da humanidade. Qualquer pessoa que executa um 
trabalho ou função para apoiar o outro está prestando ou fornecendo um serviço. Isso vale para 
um grupo de indivíduos que realiza tarefas coletivamente para dar apoio a um trabalho maior. 
Uma empresa que executa funções ou tarefas associadas aos objetivos do seu negócio 
também está fornecendo serviços. Um serviço é uma tarefa bem definida composta por 
diversas operações2 e que pode ser relativamente isolada de outras tarefas. Para que um 
1 Computação orientada a serviço é o ambiente já adequado para a lógica que foi projetada de acordo com os princípios de design da orientação 
a serviços, incluindo as novas tecnologias e plataformas.
2 Operações referem-se às operações de lógica codificada no serviço. Fazendo uma analogia com a orientação a objetos, as operações estão 
para um serviço assim como os métodos estão para uma classe.
Senac São Paulo - Todos os Direitos Reservados
Arquitetura Orientada a Serviço
3
grupo de prestadores de serviços individuais possa fornecer coletivamente um serviço maior, 
cada indivíduo precisa ter características fundamentais e comuns, como disponibilidade, 
confiabilidade e capacidade de se comunicar utilizando a mesma linguagem. Assim, esses 
indivíduos formam uma equipe funcional produtiva. O principal objetivo da orientação a 
serviços é estabelecer esses requisitos básicos.
No contexto da arquitetura orientada a serviço, o termo “serviço” é específico e se refere 
a uma combinação única de características de projeto (design). À medida que os serviços 
(lógica) são projetados repetidamente com essas características comuns, a orientação a 
serviços se torna uma realidade em todo o ambiente, assim como move a empresa para um 
estado em que sua lógica se torna cada vez menos dependente e mais agnóstica em relação 
a qualquer processo de negócio. Como resultado, aumenta amplamente o potencial de reuso 
desses serviços.
No contexto de automação de negócios, um paradigma de design é uma abordagem que 
rege o desenho ou projeto de lógica de solução. A teoria de engenharia de software conhecida 
como separação de preocupações (separation of concerns) é aplicada na construção de uma 
lógica distribuída. Esta teoria afirma que um problema maior deve ser decomposto em um 
conjunto de problemas menores ou de “preocupações” menores, ou seja, em unidades de 
lógica que resolvem cada preocupação. A resolução de cada unidade, na composição, acaba 
resolvendo o problema maior.
O principal benefício dessa forma de solucionar os problemas é que as unidades de 
lógica projetadas para resolver os interesses imediatos permanecem agnósticas em relação 
ao problema maior.
1.1 Princípios de construção (design)
Uma empresa pode possuir um único portfólio de serviços compartilhados entre todas 
as áreas ou construir diversos portfólios de serviços de domínio para cada área (ERL, 2008). 
Para entender o que é o portfólio de serviços compartilhados, veja a definição de Fugita e 
Hirama (2012, p. 21):
Um portfólio de serviços consiste em um conjunto de serviços que, de forma coletiva, 
representam funções lógicas de uma organização ou domínio. Serviços pertencentes 
a um mesmo portfólio devem formar um conjunto coeso onde as funções de um 
serviço complementam os demais e todos os serviços seguem os mesmos padrões de 
design, realização e implementação. 
Para se construir um portfólio de serviços compartilhados, a empresa deve desenvolver 
os diversos projetos de soluções orientadas a serviços com base nos princípios de construção 
(design), pois a aplicação deste paradigma nas atividades de modelagem, análise e design 
resulta em uma coleção de lógicas que pode ser realmente classificada como “orientada a 
Senac São Paulo - Todos os Direitos Reservados
Arquitetura Orientada a Serviço
4
serviços” e unidades de lógica como “serviços”. Portanto, a seguir, vamos conhecer esses 
princípios da orientação a serviços.
1.1.1 Contrato de serviço padronizado
Um serviço expressa o seu propósito e suas capacidades (funcionalidades) através de um 
contrato de serviços. O contrato inclui a interface técnica pública de um serviço, a natureza 
e a quantidade do conteúdo que será publicado, representando um acordo formal firmado 
entre o provedor do serviço e seus consumidores.
O contrato de serviço deve disponibilizar as informações sobre a localização do serviço, as 
operações executadas,as mensagens de entrada e saída utilizadas pelo serviço, as regras para a 
sua utilização e eventualmente os detalhes semânticos (significados) das operações do serviço.
1.1.2 Baixo acoplamento de serviço
Acoplamento significa ligação entre dois elementos. No contexto da orientação a serviço, 
utilizamos esse conceito como uma medida do nível de dependência entre os serviços. 
O princípio do baixo acoplamento de serviço permite que o design e a lógica de um serviço 
possam evoluir independentemente de sua implementação, ainda que a interoperabilidade 
básica com os consumidores do serviço seja garantida. Portanto, mesmo que um serviço seja 
modificado, evoluído ou substituído ao longo do tempo os consumidores não sofrerão impacto.
Existem muitos tipos de acoplamento envolvidos na construção de um serviço e para 
alcançar o nível adequado, devem ser avaliadas as opções de design de serviço que possam 
atender com equilíbrio.
1.1.3 Abstração de serviço
Abstração é o encapsulamento da lógica interna de um serviço por meio de sua interface. 
Esse princípio enfatiza a necessidade de ocultar o maior número possível de detalhes 
subjacentes de um serviço, mantendo o relacionamento com um nível baixo de acoplamento.
Os níveis de abstração aplicados ao serviço podem afetar a granularidade do contrato de 
serviços e influenciar o custo final e o esforço de administração. Quanto mais funcionalidade 
é encapsulada em um serviço, mais alta a granularidade deste serviço.
Senac São Paulo - Todos os Direitos Reservados
Arquitetura Orientada a Serviço
5
Figura 1 – Natureza da lógica e da implementação de um serviço encapsulado
Fonte: Adaptada de Erl (2008, p. 137).
1.1.4 Capacidade de reuso
Na orientação a serviço, cada serviço é projetado para ser reusável, mesmo que não 
haja requisitos específicos para isso no momento em que é desenvolvido. O serviço deve 
ser projetado considerando as várias formas de reuso como: transação entre aplicações; 
composição de serviços e processos de negócio; e uso como serviço utilitário.
Quanto mais alto o nível de granularidade de um serviço, menores são as possibilidades 
de se usar em mais de um processo de negócio. Exemplo: um serviço de gestão de clientes 
tem um nível de granularidade mais alta do que o serviço de cadastro de cliente. O primeiro 
pode incluir outros serviços (composição) e conter informações de gestão de relacionamento 
em sua lógica. Já o segundo é um serviço com nível de granularidade menor e poderia ser 
usado para cadastrar funcionários e/ou terceirizados.
Este é o princípio mais enfatizado na orientação a serviços e é importante na análise 
de serviços e processos de design. Posiciona os serviços como recursos corporativos com 
contextos funcionais agnósticos. Existem variações e níveis de reuso, assim como modelos de 
serviço agnóstico associado.
Senac São Paulo - Todos os Direitos Reservados
Arquitetura Orientada a Serviço
6
Figura 2 – Fusão do projeto do produto comercial com os métodos corporativos tradicionais
Fonte: Adaptada de Erl (ServiceOrientation.com, disponível na Midiateca da disciplina, 2015, s.p.).
1.1.5 Autonomia de serviço
A autonomia representa a capacidade de se autogovernar ou autocontrolar. Para que os 
serviços realizem suas capacidades de modo consistente e confiável, sua lógica precisa ter um 
grau significativo de controle sobre o seu ambiente e recursos. Por isso, questões relacionadas 
ao desenho da lógica e ao ambiente de implementação real do serviço são levantadas.
Este princípio suporta a realização dos outros princípios de construção (design) nos 
ambientes reais de produção, fortalecendo as características de projeto que aumentam a 
confiabilidade e a capacidade de prever o comportamento de um serviço.
Um serviço será capaz de realizar sua lógica, independentemente de influências externas, 
e deve ter o controle para se governar no ambiente de execução (runtime).
1.1.6 Independência de estado do serviço
O estado refere-se à condição em que se encontra em um determinado momento. Um 
trem que está se movendo para a próxima estação está em estado de movimento, enquanto 
que o que está parado em uma estação está no estado estacionário. 
Senac São Paulo - Todos os Direitos Reservados
Arquitetura Orientada a Serviço
7
No contexto de orientação a serviço, geralmente um programa de software em execução 
pode passar por diferentes estados e as variações das informações de estado tendem a ser 
temporárias.
Os tipos de condições e dados de estado podem ser: estados ativos e passivos; condições 
com e sem informações de estado; dados de estado de contexto, de sessão e de negócio; 
dados de contexto e regras de contexto.
Este princípio ajuda no aumento da escalabilidade do serviço, dá suporte ao design de 
lógica agnóstica e aprimora o potencial de reuso do serviço.
1.1.7 Visibilidade do serviço
Os serviços precisam ser facilmente identificados e visíveis, para que sejam descobertos 
e acessados pelos consumidores. Outro objetivo comum é permitir a busca de serviços que 
poderiam já ter as funcionalidades necessárias para reusá-los, caso contrário, seria necessário 
criar novos serviços.
As informações mais úteis que buscamos são: o propósito, as capacidades e as limitações 
de capacidades do recurso, para avaliar se será possível reusá-lo ou não.
Portanto, este princípio visa a posicionar os serviços como recursos altamente visíveis 
dentro da empresa e com informações claras sobre estes para a correta interpretação.
1.1.8 Composição de serviços
Na evolução de TI, a composição foi uma inovação fundamental para a área de design 
e tornou-se comum na arquitetura de solução personalizada, no design de produtos de 
softwares comerciais e principalmente sistemas operacionais.
A capacidade de compor efetivamente os serviços é um requisito crucial para alcançar 
alguns dos objetivos mais fundamentais da computação orientada a serviços.
Este princípio diz que os serviços devem ser componíveis3. A composição de serviços é 
uma forma de reuso de serviços, assim como o reuso possibilita a composição de serviços 
em larga escala. Se uma empresa adota estes princípios de design e estabelece uma coleção 
lógica de serviços representada por um portfólio de serviços altamente reusáveis, uma grande 
quantidade de novos requisitos da automação de negócios pode ser atendida através da 
composição de serviços.
3 Componível é no sentido de poder compor, ou seja, possibilidade para criar uma composição.
Senac São Paulo - Todos os Direitos Reservados
Arquitetura Orientada a Serviço
8
Figura 3 – Teoria da separação das preocupações
Fonte: Adaptada de Erl (ServiceOrientation.com, disponível na Midiateca da disciplina, 2015, s.p.).
1.2 Interoperabilidade
A interoperabilidade não foi classificada como um princípio porque é uma característica 
de projeto fundamental para promover a aplicação de cada um dos oito princípios relacionados 
acima.
A interoperabilidade entre os serviços é básica e deve ser possível independentemente 
da tecnologia utilizada em sua implementação. Para que os princípios da orientação a serviços 
sejam realizados com consistência e êxito, devem ser analisados os fatores ambientais, como 
a compatibilidade de protocolos de comunicação, o nível de maturidade da plataforma 
tecnológica e a adesão aos padrões de tecnologia.
Cada um dos oito princípios suporta e contribui para a interoperabilidade com o objetivo 
de torná-lo um subproduto natural até que o nível de interoperabilidade intrínseca ou 
inerente seja uma característica de design de serviço comum e esperada.
Senac São Paulo - Todos os Direitos Reservados
Arquitetura Orientada a Serviço
9
2 Vantagens da computação orientada a serviços
A computação orientada a serviços representa uma nova geração da plataforma da 
computação distribuída. Ela inclui o paradigma da orientação a serviços e a arquitetura 
orientada a serviços, com o objetivo fundamental de criar e montar um ou mais portfólios de 
serviços (ERL,2008, p. 26). 
A visão da computação orientada a serviço é bastante ambiciosa e também muito 
atraente para as empresas que querem aprimorar a eficácia de sua área de TI. Por isso, é 
importante entender os problemas já enfrentados pelas comunidades de fornecedores 
e de usuários finais dentro da indústria de TI durante a implementação da plataforma de 
computação orientada a serviços. A partir destas experiências surgiu um conjunto de 
objetivos e benefícios comuns que foram percebidos e que definem uma “receita” de sucesso 
na adoção da orientação a serviços pelas empresas.
Segundo Erl (2008, p. 35), os sete objetivos identificados estão relacionados entre si e 
podem ser classificados em objetivos estratégicos, e três deles, além de serem objetivos, são 
também benefícios resultantes.
a. Maior interoperabilidade intrínseca – a interoperabilidade é uma característica de 
sistemas capazes de se comunicar com outros para compartilhar dados. Na orientação 
a serviços a interoperabilidade é nativa nos serviços criados com a aplicação dos 
princípios e padrões de design para reduzir a necessidade de integração. Algumas das 
características de design requeridas para facilitar a interoperabilidade dos serviços 
são: padronização, escala, previsibilidade de comportamento e confiabilidade dos 
contratos. À medida que os serviços são produzidos em projetos e em momentos 
distintos, eles podem ser agrupados em várias configurações de composição para 
automatizar diferentes tarefas de negócio.
b. Maior federação – federação é unir coisas diferentes para que elas possam agir como 
uma. Os recursos de TI e os aplicativos podem ser unidos, ainda que se mantenha a 
autonomia individual e a autogovernança. A federação em SOA permite aumentar as 
implementações em larga escala de serviços padronizados e capazes de se compor. 
É possível atingir um nível mais alto de federação se utilizarmos a tecnologia Web 
services para construir as soluções orientadas a serviços, ou seja, aplicando os 
princípios de padrões e de design.
c. Mais opções de diversificação de fornecedores – todos nós queremos escolher 
inovações tecnológicas e produtos do “melhor fornecedor da categoria” e também 
queremos utilizá-los conjuntamente com os recursos que já existem na empresa. 
Para que a empresa possa ter esta opção de escolha, é importante que a arquitetura 
da tecnologia a ser adquirida não esteja associada ou atada à plataforma de um 
fornecedor específico. Isso dá liberdade à empresa de mudar, ampliar ou substituir 
Senac São Paulo - Todos os Direitos Reservados
Arquitetura Orientada a Serviço
10
algumas soluções sem interromper toda a arquitetura de serviço federada. Os Web 
services reduzem ainda mais a dependência das plataformas de fornecedor porque 
não impõem requisitos de comunicação proprietária. Assim, o tempo de vida da 
solução é prolongado e o retorno sobre o investimento é aumentado.
d. Maior alinhamento do domínio de negócio e de tecnologia – era comum a falta 
de precisão na transformação dos requisitos de negócio em implementação da 
lógica de uma solução. Graças ao paradigma de design, que promove a abstração 
em vários níveis, é possível aplicar a abstração funcional em camadas de serviço que 
encapsulem e representem precisamente os modelos de negócios.
e. Maior retorno sobre o investimento (ROI4) – a complexidade da natureza da lógica 
dos aplicativos aumentou, as arquiteturas ainda não são federadas e o processo de 
integração ainda crescente: esses são os inibidores para que um departamento de TI 
se mantenha e evolua, sem que ele represente um valor significativo no orçamento 
operacional total de uma empresa. A utilização de lógica de solução agnóstica 
que possa atender a vários objetivos e ser reusável tira proveito da natureza de 
interoperabilidade inerente nos serviços criados sob os princípios de design.
f. Maior agilidade organizacional – a agilidade empresarial está relacionada à eficiência 
com que a empresa responde às mudanças de mercado. Muitas vezes o departamento 
de TI é visto como um “gargalo” que dificulta a capacidade de resposta desejada, 
pois exige tempo e recursos demasiados para atender a novos requisitos de negócio. 
À medida que o portfólio de serviços é composto por uma porcentagem maior de 
serviços agnósticos, estes podem ser posicionados como ativos de TI reusáveis, e 
que podem ser repetidamente compostos em diferentes configurações. Portanto, 
o tempo e o esforço necessários para automatizar novos processos de negócio ou 
modificar algum existente são reduzidos proporcionalmente.
g. Menor carga de trabalho de TI – o departamento de TI de uma empresa que aplica 
consistentemente a orientação a serviços ao longo do tempo apresenta menor 
desperdício e redundância, menor tamanho e custo operacional e menos despesas 
indiretas associadas à governança e evolução. Portanto, uma TI mais ágil e mais 
enxuta que contribui mais para os objetivos estratégicos da empresa.
4 ROI vem do termo em inglês Return Of Investment, ou seja, retorno sobre o investimento. Aqui no Brasil é muito utilizado em inglês mesmo.
Senac São Paulo - Todos os Direitos Reservados
Arquitetura Orientada a Serviço
11
Figura 4 – Representação dos objetivos e benefícios de SOA
Fonte: Adaptada de Erl (2008, p. 35). 
Para concluir o entendimento desses oito objetivos e benefícios, segue o resumo dos 
pontos-chave de Erl (2008, p. 40):
Os benefícios-chave da computação orientada a serviços estão associados com 
a padronização, a coerência, a confiabilidade e a escala estabelecidas dentro dos 
serviços por meio da aplicação dos princípios de design da orientação a serviços.
A plataforma de computação orientada a serviços fornece o potencial de aumentar a 
capacidade de resposta e a rentabilidade econômica da TI por meio de um paradigma 
de design que enfatiza os objetivos e benefícios estratégicos.
Considerações finais
Nesta aula foi possível entender como é possível obter os benefícios tão atraentes da 
arquitetura orientada a serviço. Benefícios estes que impactam positivamente os negócios 
de uma empresa. 
Mas, lembre-se, “não há almoço grátis” para se obter o sucesso. Devemos entender 
os objetivos que se quer alcançar, estudar e planejar para saber como fazer e seguir os 
princípios da orientação a serviços que ajudarão a reduzir os riscos e manter a governança, a 
produtividade, a flexibilidade e a escalabilidade do processo como um todo. 
Independentemente da escolha de começar com uma única iniciativa para construir 
o portfólio (neste caso com investimento inicial mais alto) ou várias iniciativas em uma 
abordagem incremental, esta é uma jornada muito estimulante que integrará a empresa toda 
e o deixará preparado para incluir novos projetos inovadores com mais agilidade graças à 
arquitetura adotada.
Senac São Paulo - Todos os Direitos Reservados
Arquitetura Orientada a Serviço
12
Ao atingir a maturidade na adoção da arquitetura orientada a serviço, a empresa se 
tornará mais competitiva graças à sua agilidade, resiliência5 e responsividade6 ao mercado. 
Os resultados serão parecidos com os percebidos por muitas outras empresas do mercado, 
que estão usufruindo o sucesso.
Referências
ERL, Thomas. Service Orientation: Service-Orientation Design Principles. Disponível em: 
<http://serviceorientation.com/serviceorientation/index>. Acesso em: 15 jul. 2015.
______. SOA: Princípios de design de serviços. São Paulo: Prentice Hall, 2008.
FUGITA, Henrique Shoiti; HIRAMA, Kechi. SOA: modelagem, análise e design. Rio de Janeiro: 
Elsevier, 2012.
Imagem Fusão do projeto: ERL, Thomas. Service Orientation. Disponível em: <http://
serviceorientation.com/serviceorientation/service_reusability>. Acesso em: 15 jul. 2015.
Imagem Teoria da separação das preocupações: ERL, Thomas. Service Orientation. Disponível 
em: <http://serviceorientation.com/serviceorientation/service_composability>. Acesso em: 15 
jul. 2015.
5 Resiliência é usada neste contexto para definir a capacidade de umaempresa não “sentir tanto” o impacto de um evento negativo no 
mercado, por estar organizada de forma que consegue absorver com menos “dor”.
6 Responsividade é usada para expressar a capacidade da empresa em responder rápido ao mercado quando há oportunidades não previstas. 
Responder inclui perceber logo e agir no contexto da oportunidade.
Arquitetura Orientada a Serviço
Aula 03
Fundamentos da SOA: Arquitetura Distribuída e Sistemas de 
Softwares
Objetivos Específicos
• Identificar os tipos de softwares existentes e compreender como a SOA 
integra aplicações de tecnologia distintas.
Temas
Introdução
1 Saindo do modelo de silos para a arquitetura distribuída
2 A computação distribuída
3 A importância da criação de padrões
4 Softwares importantes para a SOA
Considerações finais
Referências
Mikiko Ishida
Professor Autor
Senac São Paulo - Todos os Direitos Reservados
Arquitetura Orientada a Serviço
2
Introdução
Como chegamos à arquitetura orientada a serviço?
De aplicações monolíticas à arquitetura de sistemas distribuídos até chegar à arquitetura 
orientada a serviço. Como foi possível? Quais são os softwares1 ou tecnologias que ajudam a 
aplicar realmente os princípios da orientação a serviços?
Nesta aula, vamos voltar um pouco no tempo e ver as respostas a essas perguntas e 
também entender como tudo se encaixa através da arquitetura de software, que viabiliza a 
implementação das regras, as quais devem ser cumpridas para que a orientação a serviços e 
seus princípios sejam continuamente aplicados.
1 Saindo do modelo de silos para a arquitetura distribuída
No início da Tecnologia da Informação, o “usuário” (quem solicitava um sistema para 
automatizar ou resolver um problema) explicava quais funcionalidades queria e o programador 
anotava o que entendia para começar a codificar o programa, sem criar uma arquitetura. À 
medida que os negócios evoluíram e os requisitos aumentaram, os programadores criaram 
estruturas sistemáticas para organizar os programas e o negócio. Assim começou a arquitetura, 
no começo, qualquer design básico de um sistema era conhecido como uma arquitetura.
Ao descrever uma estrutura de software, os princípios de design fundamentais 
aplicados são chamados de “arquitetura de software”. A ideia da arquitetura implica em 
um planejamento de acordo com um conjunto de diretrizes e regras. Uma boa arquitetura 
de software especifica como os dados são armazenados, como os usuários interagem com o 
sistema, como os programas se comunicam e assim por diante.
Na ciência da computação, a arquitetura descreve o design geral e a estrutura de um 
sistema de computador. Já os diagramas de arquitetura de software descrevem os componentes 
de um sistema de computação, oferecendo indicação de como eles se conectam e interagem 
(HURWITZ et al., 2009, p. 45).
Na época dos silos, as empresas ou governos tinham aplicações de software especializadas 
para executar funções de negócio, por exemplo, receber e executar um pedido de cliente. 
Porém, a otimização dos processos de negócio demandou a necessidade de interagir com 
outros sistemas para acessar informações de locais diferentes. A necessidade de integrar 
outros sistemas implicava em altos custos e esforços, levando muitas vezes os programadores 
a criarem novos códigos para resolver o problema, por exemplo, criando uma base replicada 
de outro sistema, o que, consequentemente, resultou em mais silos. Veja a seguir uma figura 
ilustrativa (Figura 1) para entender o que acontecia com uma aplicação.
1 Softwares são programas de computador, as estruturas de dados e a documentação associada juntos. Os softwares podem ser: sistema 
básico: do tipo editor, compilador, sistemas operacionais, drivers; aplicação ou aplicativo: controla os negócios e processos; embutido; Web e 
legado.
Senac São Paulo - Todos os Direitos Reservados
Arquitetura Orientada a Serviço
3
Figura 1 – Aplicação monolítica – todos os tipos de operação em um bloco autocontido
Fonte: Adaptada de IBM (2015).
2 A computação distribuída
A computação distribuída surgiu para atender à necessidade de integração entre sistemas 
que estão em computadores de locais diferentes, para realizar uma tarefa de negócio. 
É um termo que descreve uma arquitetura de hardware e software em que mais de um 
computador participa da realização de determinada tarefa. Veja como Pulier e Taylor (2008, 
p. 7) descrevem a computação distribuída. 
Cada computador que participa da execução da tarefa de negócio deve ser apto a se 
comunicar com o outro computador ou outros computadores envolvidos na tarefa. E 
como os computadores em ambiente distribuído se comunicam? As máquinas podem 
se comunicar através de uma variedade de métodos, da Internet à Rede de Longa 
Distância (WANs2) ou Redes Locais (LANs3) dedicadas. 
Virtualmente, mensagens são a fonte de todas as questões e soluções relacionadas ao 
gerenciamento de computação distribuída. 
A troca eletrônica de dados (EDI4), a integração de aplicações corporativas (EAI5) ou 
outras formas com as quais os fornecedores de TI tentam resolver os desafios da computação 
distribuída realizam a transmissão, o recebimento e a resposta a mensagens entre os 
computadores envolvidos para solucionar a necessidade de integração.
2 WAN vem do termo em inglês, Wide Area Network.
3 LAN vem do termo em inglês, Local Area Network.
4 EDI vem do termo em inglês, Electronic Data Interchange.
5 EAI vem do termo em inglês, Enterprise Application Integration.
Senac São Paulo - Todos os Direitos Reservados
Arquitetura Orientada a Serviço
4
Já o Web service é uma evolução dessas técnicas utilizadas para transmitir mensagens 
entre computadores em ambientes distribuídos e mais, com padronização.
2.1 Problemas da interoperabilidade
Geralmente, os computadores eram de diferentes fabricantes com diferentes sistemas 
operacionais, que rodavam vários softwares escritos também de forma diferente e por 
equipes distintas. Ou seja, as informações não eram entendidas e nem transmitidas de forma 
compatível. Os sistemas precisavam de um “tradutor” entre eles, ou seja, uma interface.
Uma interface é como um software (intermediário), que interpreta e transmite 
mensagens entre dois computadores que estão operando em uma arquitetura distribuída, 
representada na Figura 2. E é claro que esta interface precisa estar disponível para que esta 
comunicação aconteça. Porém, a partir do uso de interfaces alguns problemas surgiram.
Figura 2 – Primeira forma de integração – início da computação distribuída
Fonte: Adaptada de Pulier e Taylor,(2008, p. 9).
Na computação distribuída, as interfaces de software servem como intermediárias de 
processamento de mensagens entre computadores que precisam se comunicar. Algumas 
características das interfaces desta época são: 
a. Padrões proprietários – a utilização de interfaces feitas sob medida começou a 
crescer. Quando havia necessidade de criar uma comunicação entre um sistema e 
o outro, ao tentar reutilizar a interface já existente, verificava-se que não atendia 
totalmente à necessidade e o programador geralmente decidia escrever outra 
interface específica para o novo problema que estava sendo solucionado. Com isso, o 
volume de interfaces do tipo sob medida aumentou, contendo padrões proprietários 
e funções redundantes.
Senac São Paulo - Todos os Direitos Reservados
Arquitetura Orientada a Serviço
5
b. Acoplamento forte – a adição de novos computadores a uma interface existente 
que trabalha com padrão proprietários adiciona mais código proprietário e cria uma 
arquitetura de integração fortemente acoplada (Figura 3). E a cada novo sistema 
que precisar se comunicar com estes já existentes, precisará criar um programa de 
interface de software para estabelecer a conectividade. Qualquer mudança que seja 
requerida neste cenário implica em gastar muito tempo e dinheiro. Cada computador 
tem suas próprias “fechadura e chave” para transmitir e receber mensagens. Neste 
contexto, a expressão“fechadura e chave” faz uma analogia ao conjunto de TI: sistema 
operacional, linguagem de programação e protocolos de comunicação.
Figura 3 – Forte acoplamento devido às interfaces com padrão proprietário
Fonte: Adaptada de Pulier e Taylor (2008, p.10). 
Houve desespero em muitas empresas por causa de interfaces caras, proprietárias ou 
customizadas. Bilhões de dólares foram despendidos, afetando os caixas e até os valores de 
ações de várias companhias do mundo. Esses problemas são o resultado de uma condição 
em que os negócios precisavam utilizar numerosos computadores diferentes para realizar as 
tarefas, porém, sem um padrão comum para tornar o processo eficiente.
Todos entendiam que era necessário criar padrões para as mensagens entre os 
computadores. Para isso, os grandes fornecedores que desenvolviam um conjunto de 
tecnologias para as suas próprias plataformas precisavam entrar em um acordo e participar 
da definição dos padrões que seriam utilizados por todos. E foi o que aconteceu.
Senac São Paulo - Todos os Direitos Reservados
Arquitetura Orientada a Serviço
6
2.2 O advento da orientação a objeto
Enquanto as organizações se tornavam cada vez mais alicerçadas na informação, surgia 
uma maior necessidade de sistemas. O problema não era o hardware, pois este evoluía 
rapidamente, aumentando o seu poder de processamento a uma velocidade incrível. O 
problema era o software, pois construir um software que pudesse aproveitar a capacidade 
de processamento dos poderosos computadores era um grande desafio. O processo de 
desenvolvimento de softwares era muito lento e geralmente acabava custando acima do 
orçamento. Esta situação ficou conhecida como a “crise do software”.
Assim, chegou-se à abordagem do software orientado a objetos, que proveu a base para 
um passo importante em direção ao framework conceitual para os sistemas distribuídos 
interoperáveis. Pois, a orientação a objetos é um modelo de análise, projeto e implementação 
de sistemas de software baseado na composição e interação entre diversas unidades de 
software chamadas de objetos.
Para quem quiser conhecer, há um livro já antigo, mas muito interessante, que compara 
o objeto com uma célula orgânica em vários aspectos como: encapsulamento de dados e 
comportamento, a comunicação via mensagens, a constituição por blocos, a hierarquia dos 
tipos de células com a hierarquia de objetos etc. O livro é o seguinte: TAYLOR, David A. Object-
Oriented Technology: A Manager’s Guide. EUA: Addison-Wesley, 1990.
A orientação a objetos introduziu vários conceitos que depois foram adotados pela 
orientação a serviços. Um dos objetivos da computação orientada a objetos era alcançar a 
reutilização e baixar o custo do desenvolvimento de aplicações. Porém, o fato de não haver 
um software orientado a objetos multilinguagem universal não incentivava os programadores 
a reutilizar os códigos existentes. Isso porque mesmo que encontrasse um código para reuso, 
poderia estar em outra linguagem não compatível com o sistema operacional onde rodará 
este sistema. Com isso, não obtiveram a interoperabilidade desejada entre sistemas e a 
utilidade do reuso ficou limitada até a chegada dos Web services. Veja como Pulier e Taylor 
definem Web services de forma abrangente:
Os Web services disponibilizam funcionalidades maiores como componentes 
de software reutilizáveis que podem interoperar entre diferentes linguagens de 
programação, elevando assim, o conceito de reutilização a novos patamares, 
eliminando potencialmente as dificuldades de interfaces proprietárias ou 
customizadas que conectam um sistema a outros. (PULIER; TAYLOR, 2008, p. 16).
Senac São Paulo - Todos os Direitos Reservados
Arquitetura Orientada a Serviço
7
2.3 O surgimento da arquitetura cliente-servidor
A área de Tecnologia da Informação avançou novamente com o surgimento da 
computação cliente-servidor. Cliente-servidor descreve uma arquitetura de software em que 
um programa de computador (o cliente) solicita dados ou funcionalidade de outro software, 
geralmente em um computador remoto, que é conhecido como servidor (PULIER; TAYLOR, 
2008, p. 16). Esta arquitetura está exemplificada na Figura 4: 
Figura 4 – Exemplo de transação CLIENTE-SERVIDOR
A arquitetura cliente-servidor é a essência do Web services e da arquitetura orientada a 
serviços. A geração de arquitetos e desenvolvedores de softwares aprenderam a observar as 
vantagens de se criar sistemas distribuídos baseados em mensagens. Com o surgimento da 
internet, ficou mais claro o poder dos padrões abertos quando aplicados à arquitetura cliente-
servidor, e desta forma foram criadas as condições para o desenvolvimento dos padrões de 
Web services.
3 A importância da criação de padrões
Na Tecnologia da Informação, os órgãos padronizadores são grupos industriais 
colaborativos sem fins lucrativos que desenvolvem e publicam os padrões que são utilizados 
para se desenvolver tecnologia. Existem vários órgãos padronizadores, mas os mais impor-
tantes a se destacar neste momento são: o W3C (Web Services Interoperability Organization 
– WS-I) e o OASIS (Organization for the Advancement of Structured Information Standards).
Para entender a importância, por exemplo, o W3C publica as especificações do HTML 
(Hypertext Markup Language) para garantir que todos os navegadores web possam ler os 
documentos HTML que se encontram na Web. Sem esta padronização, haveria risco de que 
sites web começassem a oferecer conteúdos que somente certos clientes poderiam entender, 
ou seja, a Web seria um fracasso.
O aspecto mais crucial dos padrões é que sejam abertos, ou seja, um padrão que não 
pertença a nenhuma companhia ou organização que possa cobrar ou restringir o seu uso.
Senac São Paulo - Todos os Direitos Reservados
Arquitetura Orientada a Serviço
8
4 Softwares importantes para a SOA
A Rede Mundial de Computadores (Web) realmente deslanchou em 1994 e se tornou 
um veículo onipresente para a prestação de serviços no mundo. Quando algumas empresas 
da indústria química e aço usaram serviços na Web para estabelecer mercados online para 
melhorar a eficiência de gestão da cadeia de fornecedores, estranhamente, o software que 
executava estes serviços na Web ficou conhecido como software de Web services.
4.1 Do SGML ao HTML e XML
O Extensible Markup Language (XML), assim com o HTML, foi criado pela W3C para gerar 
linguagens de marcação para algumas necessidades específicas. 
Um Markup language é um conjunto de instruções que você adiciona a uma coleção de 
palavras, figuras, tabelas e outras coisas para definir precisamente como esta coleção deve 
ser exibida em uma folha de papel, em uma tela de computador ou onde quiser exibi-la. O 
extensible quer dizer extensível, no sentido de poder estender capacidades, possibilidades e 
interoperabilidades.
O XML e o HTML foram derivados do popular Standard Generalized Markup Language 
(SGML), que já existia desde o final dos anos 1960, mas não era adequado para uso na 
internet. Portanto, o HTML foi criado em 1986 e depois o XML foi criado em 1998, pois 
surgiu a necessidade de uma linguagem de marcação padrão, já que a Netscape e a Microsoft 
estavam em disputa intensa com suas versões de HTML. 
Outro motivador para a criação do XML é que não era possível prever todas as diferentes 
tags (linguagem de marcação) que poderiam ser necessárias para marcar os novos tipos de 
conteúdo. Era necessária uma linguagem que fosse extensível, que pudesse ser aumentada 
para suportar qualquer coisa nova que pudesse acontecer. O quadro 1 exemplifica um XML: 
Quadro 1 – Exemplo de como funciona um XML
<Mensagem>
<Para> Você, caro aluno </Para>
<de> Professores do SENAC </De>
<Título> Dica útil </Título>
<Mensagem_texto> Vale lembrar que tags XML podem seru sadas 
para definir itens de dados. E você pode inventar todasas que 
precisa. As pessoas dizem que XML é extensível. 
E elas não estão erradas.<Mensagem_texto> 
</Mensagem>
Fonte: Adaptada de Hurwitz et al. (2009, p.120).Senac São Paulo - Todos os Direitos Reservados
Arquitetura Orientada a Serviço
9
Além de entender o poder de XML, é importante observar que ele trabalha junto com 
outros padrões importantes para realizar a comunicação na Web e também com uma variedade 
de padrões Web services. A seguir, no Quadro 2, são listados alguns destes principais padrões: 
Quadro 2 – Padrões para realização da comunicação WEB
Padrão 
SOA
O que significa O que é & para que é usado
HTTP Hyper Text Transfer Protocol
Padrão de endereço de páginas Web. 
Além de definir um endereço, HTTP também pode identificar 
um Web service. Ex.: o serviço de alertas que o Google 
oferece.
XML eXtensible Markup Language
Linguagem de definição que pode acompanhar informações. 
Ela diz a um programa de computador o que são realmente 
estas informações.
SOAP
Simple Object Access Protocol 
(simples protocolo de acesso 
ao objeto)
Padrão que usa XML para descrever mensagens enviadas 
de um programa para outro. Um programa usa SOAP para 
solicitar um serviço de outro programa e, então, passar a ele 
dados relacionados.
WSDL
Web Services Description 
Language (linguagem de 
descrição de Web services)
Padrão baseado em XML. Programadores usam WSDL para 
criar um documento XML, que descreve um Web service e 
como acessá-lo.
UDDI
Universal Description, Discovery 
and Integration (descrição, 
descoberta e integração geral)
Framework para fazer o que sugere: descrever, descobrir e 
integrar serviços de negócio através da internet. 
O framework UDDI usa SOAP para se comunicar com 
programas que o acessam.
REST
REpresentational State Transfer 
(transferência de estado 
representacional)
Interface simples para transferir dados através de HTTP sem 
as complicações adicionadas de uma camada de mensagem 
como SOAP ou o uso de rastreamento de sessão através de 
cookies HTTP. 
Pode ser usada para criar uma arquitetura.
Fonte: Hurwitz et al. (2009, p.120-121).
Este conjunto de padrões pode ser descrito, de forma simplificada, através da quadro 3: 
Quadro 3 – Simplificando a tabela de padrões para comunicação WEB
√ HTTP – endereço
√ XML – decodifica mensagens
√ SOAP – escreve mensagens
√ WSDL – descreve interfaces
√ UDDI – diretório para encontrar serviços, como diretório de telefone
√ REST – maneira simples de transferir dados pela Web e pode ser usado 
para criar arquiteturas sem estado
Fonte: Hurwitz et al. (2009, p.120-121).
Senac São Paulo - Todos os Direitos Reservados
Arquitetura Orientada a Serviço
10
A versatilidade do XML é o que o faz diferente das tecnologias de componentes das 
gerações anteriores. Como o XML permite separar a estrutura gramatical (sintaxe) do 
significado gramatical (semântica) e separar o “como é processado e entendido por cada 
serviço” do ambiente onde ele existe, é possível definir objetos como serviços que se 
comunicam com outros serviços usando a gramática definida por XML, e cada serviço traduz 
e analisa a mensagem de acordo com sua implementação local e o seu ambiente.
Para conhecer mais sobre XML e definições como XML Schema, acesse IBM – Introduction 
to XML. Para saber mais, acesso o link disponível na Midiateca da aula.
4.2 Web services
O Web service é uma interface de software que descreve uma coleção de operações que 
podem ser acessados pela rede através de mensagens XML. Ele utiliza protocolos baseados 
na linguagem XML que descreve uma operação para executar ou trocar dados com outro Web 
service. Uma determinada aplicação Web service em uma arquitetura orientada a serviço 
poderia ser um grupo de Web services interagindo entre si (IBM, 2015).
O XML descreve todo e qualquer dado de maneira realmente independente de plataforma 
para realizar o intercâmbio entre os sistemas. Com o fato do Web service usar o XML, se 
tornou possível a criação de aplicações de baixo acoplamento ou fracamente acoplado 
e, também, por funcionar em um nível mais abstrato, permite manipular dados de forma 
dinâmica e sob demanda.
Por essa razão, os Web services estão ajudando a preencher a lacuna entre os empresários 
e tecnólogos de uma organização, facilitando o entendimento e alinhamento entre eles. 
Agora os executivos de negócio podem descrever os eventos e as atividades que desejam aos 
tecnólogos e estes conseguem associá-los aos serviços adequados.
As interfaces definidas universalmente e as tarefas bem desenhadas tornam realidade 
a reutilização das tarefas e dos aplicativos que elas representam, trazendo assim um melhor 
retorno sobre o investimento em software, pois é possível produzir mais com os mesmos 
recursos. Inclusive, as áreas de negócio podem considerar o uso de um aplicativo existente 
dentro de uma nova oferta ou como um novo produto adicionando benefícios, potencializando, 
assim, o aumento de transações comerciais entre os parceiros de negócio.
Senac São Paulo - Todos os Direitos Reservados
Arquitetura Orientada a Serviço
11
Considerações finais
A arquitetura orientada a serviços foi estruturada sobre as melhores práticas que utilizam 
tecnologias, assim como modelos de desenvolvimento para tornar realidade a construção de 
serviços interoperáveis que apoiam o atingimento dos objetivos de negócio e de TI. 
Nesta aula descrevemos as principais tecnologias e recursos de TI que fundamentam 
a implementação, ou seja, viabilizam os princípios da orientação a serviços. E como vimos, 
eles são chave para alcançar a tão desejada interoperabilidade entre os serviços, sistemas e 
plataformas.
As tecnologias passadas, as limitações dos softwares, os problemas enfrentados com a 
falta de controle ou governança e a evolução dinâmica do negócio, tudo isso ajudou a motivar 
a criação de novos recursos e melhores para que pudéssemos chegar até aqui.
Figura 5 – Evolução tecnológica até chegar na Arquitetura Orientada a Serviço
Portanto, a arquitetura orientada a serviço abraçou todas essas tecnologias que surgiram 
para facilitar a implementação das características dos princípios de design da orientação a 
serviços, da computação distribuída e dos padrões abertos e universais.
Apenas para lembrar, a seguir os princípios de design da orientação a serviços:
Figura 6 - Princípios de design da orientação a serviços
Senac São Paulo - Todos os Direitos Reservados
Arquitetura Orientada a Serviço
12
E um aspecto-chave mais abrangente e que está relacionado com todos esses anteriores: 
a interoperabilidade intrínseca.
Referências
HURWITZ, Judith et al. Arquitetura Orientada a Serviços: SOA para Leigos. Rio de Janeiro: Alta 
Books, 2009.
__________; BLOOR, Robin; KAUFMAN, Marcia; HALPER, Dra. Fern. Arquitetura Orientada a 
Serviços – SOA para Leigos. Rio de Janeiro: Alta Books, 2009.
IBM DEVELOPERWORKS. Technical topics: New to SOA and web services. Disponível em: <http://
www.ibm.com/developerworks/webservices/newto/service.html>. Acesso em: 2 jul. 2015.
PULIER, Eric; TAYLOR, Hugh. Compreendendo SOA Corporativa. Rio de Janeiro: Ciência 
Moderna, 2008. 
Arquitetura Orientada a Serviço
Aula 04
SOA sob a ótica de negócio
Objetivos Específicos
• Abordar os principais componentes da arquitetura que permitem um maior 
controle sobre os serviços de TI.
Temas
Introdução
1 Os desafios que os componentes SOA ajudam a resolver
2 Barramento de serviço corporativo
3 Registro e repositório SOA
4 Gerenciador de orquestração de processos de negócio
5 Service broker
6 Gerenciador de serviço SOA
Considerações finais
Referências
Mikiko Ishida
Professor Autor
Senac São Paulo - Todos os Direitos Reservados
Arquitetura Orientada a Serviço
2
Introdução
Vamos conhecer os principais componentes da arquitetura orientada a serviço (SOA) 
que permitem torná-la realidade, seguindo os princípios da orientação a serviço, para trazer 
os benefícios de negócio esperados pelas empresas.
Cada um desses componentes de SOA (representados na Figura 1) desempenha o seu 
papel, funciona de forma independente, mas também interage um com o outro. Quanto 
mais sintonizados esses componentes estiverementre si, melhor será o nível de serviço que 
a arquitetura orientada a serviço fornecerá ao negócio.
Figura 1 – Componentes fundamentais da Arquitetura Orientada a Serviço (SOA)
Fonte: Adaptada de Hurwitz et al. (2009, p. 72). 
O ESB1 (barramento de serviço corporativo): ajuda a enviar e receber as mensagens 
entre os componentes de uma implementação SOA. 
• O registro e repositório SOA: contém informações de referência importantes para a 
localização dos componentes de SOA. 
• O gerenciador de orquestração de processos de negócio: provê a tecnologia para 
conectar pessoas com pessoas, pessoas com processos e processos com processos. 
• O service broker ou o mediador de serviço: conecta serviços com serviços, viabilizando 
o fluxo de processo de negócio. 
• O papel do gerenciador de serviço SOA é garantir que o ambiente SOA e a tecnologia 
que o suporta funcionem consistentemente e de forma previsível. O objetivo é criar 
1 ESB vem do termo em inglês Enterprise Service Bus, ou seja, barramento de serviço corporativo ou apenas barramento de serviço. É onde 
acontecem as comunicações entre os serviços da arquitetura orientada a serviço.
Senac São Paulo - Todos os Direitos Reservados
Arquitetura Orientada a Serviço
3
um ambiente onde todos os serviços que trabalham juntos possam ser conectados a 
componentes de tecnologia ainda não relacionados, como se tivessem sido projetados 
para trabalhar juntos e, assim, possam melhorar o fluxo do processo de negócio.
1 Os desafios que os componentes SOA ajudam a resolver
1.1 Separação de interesses
O mundo de SOA pode ser dividido em camada de serviços de negócio e camada de 
plumbing (termo em inglês que lembra um encanamento, que leva o conteúdo para vários 
pontos da rede). A primeira contém a lógica de negócio e a segunda lida com os recursos da 
computação.
Um dos maiores desafios do desenvolvimento de aplicações de negócio é conseguir 
manter a lógica de negócio (ex.: incluir uma linha de pedido; atualizar o saldo em estoque; 
agendar a entrega via transportadora etc.) separada da lógica de plumbing (ex.: abrir conexão 
com o banco de dados ABC; verificar se a impressora está conectada etc.). 
Figura 2 – Exemplo de separação de interesses (camada de negócio da camada de” plumbing”)
Fonte: Adaptada de Hurwitz et al. (2009, p. 51). 
Utilizando ferramentas de software apropriadas e disciplina do desenvolvedor para 
garantir esta separação, é possível manter a lógica de negócio separada da tecnologia que a 
faz acontecer.
A separação de interesses é frequentemente ignorada por requerer mais tempo 
e esforço, porém, no futuro, os custos desta decisão serão altos. Criar uma arquitetura 
reutilizável exige disciplina e os gestores de TI precisam ser instruídos para que estejam 
cientes. O esforço inicial e exigência da disciplina são pagos ao longo do tempo, com 
dividendos.
Senac São Paulo - Todos os Direitos Reservados
Arquitetura Orientada a Serviço
4
1.2 Reutilização do sistema legado como serviço
Com o SOA, muitas aplicações de negócio existentes poderão ser tratadas como serviço, 
ou parte delas pode ser extraída e colocada em um novo serviço. Para incluí-las na arquitetura 
SOA, algumas alterações ou a adição de adaptadores ou interfaces poderão ser necessárias.
A criação de um adaptador pode não ser simples, mas sua função é clara. Permite 
conectar uma aplicação de negócio existente (legado) à arquitetura SOA. A arquitetura SOA 
utiliza padrões específicos e, de acordo com a indústria, é possível criar essas interfaces que 
permitam a vários componentes se comunicarem como componentes SOA.
Após criar todos os elementos exigidos pela arquitetura SOA, você pode incluir uma 
aplicação existente ou parte dela, dentro do framework SOA.
Os fornecedores de pacotes de software têm oferecido adaptadores para conectar o 
pacote à sua arquitetura SOA.
Figura 3 – Cenário com acréscimo de aplicação existente na composição de serviços do exemplo anterior
Fonte: Adaptada de Hurwitz et al. (2009, p. 53). 
1.3 Aplicação existente tratada como caixa-preta
A SOA também é definida como uma arquitetura de componente caixa-preta, pois 
esconde a complexidade deliberadamente sempre que possível. A caixa-preta permite a 
reutilização de aplicações de negócios existentes, adicionando um adaptador simples nelas 
sem importar com a forma como foram construídas.
Apesar de dividir a arquitetura em camadas de negócio e de plumbing, muitos 
componentes da camada de negócio vêm de aplicações existentes que foram criadas de 
formas diferentes e incluem tudo como lógica de aplicação. Muitas vezes são aplicações 
antigas e sem fonte, mas funcionam e são críticas para o negócio da empresa ainda hoje.
Senac São Paulo - Todos os Direitos Reservados
Arquitetura Orientada a Serviço
5
Portanto, são chamadas de caixa-preta, pois não é possível entender como foram 
construídas e não são acessíveis. Mesmo que não saibamos como foram desenvolvidas, 
sabemos como utilizá-las. Com SOA é possível tratar essas caixas-pretas como componentes 
de serviço, adicionando adaptadores para que possam interagir com os novos componentes.
1.4 Coordenação de componentes
Ao colocar as aplicações antigas e “bagunçadas” em caixas-pretas, não significa que tudo 
vai correr bem. É necessário saber como essas caixas-pretas serão unidas para garantir o 
serviço de ponta a ponta. São muitas variáveis e o plumbing de cada caixa-preta pode ser 
totalmente diferente. Se um deles não funcionar, como saber?
Um gerenciador de serviços SOA é necessário para coordenar o processamento de 
todos estes componentes. O gerenciador de serviços SOA é um ambiente de gerenciamento 
virtualizado que age como um guarda de trânsito que tenta monitorar o tráfego, com a 
intenção de garantir que acidentes não ocorram.
2 Barramento de serviço corporativo
A arquitetura orientada a serviço é um paradigma de construção e integração. Todos os 
diferentes pedaços de software que participam de SOA se comunicam enviando e recebendo 
muitas mensagens. Essas mensagens precisam ser entregues com rapidez e seu recebimento 
deve ser garantido, pois são críticas para a entrega de serviço de negócio de ponta a ponta. 
Sem isso, não há serviço.
Portanto, o transporte de mensagens entre os componentes de software na arquitetura 
orientada a serviço é realizado no Barramento de Serviço Corporativo (ESB). O barramento 
de serviço corporativo é tão importante para a SOA que muita gente pensa que sem ele 
não é possível ter SOA ou acham que o fato de ter um ESB implementado significa que já 
conquistaram SOA. Nenhuma dessas alternativas é verdade. A utilização deste barramento 
não é obrigatório; porém, a comunicação entre os serviços é necessária e, por isso, muitas 
empresas optaram por utilizar o ESB para realizar a integração universal dos serviços.
Podemos imaginar o ESB como uma camada especial que roda sobre a rede de 
comunicação e oferece um serviço de mensagens garantido entre os componentes SOA.
De fato, o barramento de serviço é um middleware2 que possibilita a comunicação entre 
vários elementos de uma solução orientada a serviços. Ele viabiliza a arquitetura orientada 
a serviço conectando um ambiente heterogêneo com diversas tecnologias e protocolos 
de comunicação, permitindo inclusive a criação de serviços a partir de aplicações legadas, 
através de mediações.
2 Middleware é uma camada de software que permite conectar diferentes aplicações de software em sistemas distribuídos.
Senac São Paulo - Todos os Direitos Reservados
Arquitetura Orientada a Serviço
6
Nos diagramas de arquitetura, geralmente o ESB é representado com um cano separado 
onde os componentes de software se conectam e por onde as informações e instruções fluem. 
Na Figura 4 temos esta representação. Na realidade, o ESB é uma coleção de componentes de 
software que gerencia mensagens de um componente de software para outro. Ao se conectar 
no ESB, um componente de software passa uma mensagem em um formato específico