Arquitetura Orientada a Serviços (SOA)

Nayara Andressa1, William Fontanin Rodrigues1, Diego Doná1

1
Faculdade Salesiana Dom Bosco – Piracicaba – SP – Brasil
nayara.dessa@gmail.com, rodrigueswilliamf@gmail.com, diedona@gmail.com

Abstract. Information Technology and the business are essential pieces for
any corporation. Today, they live in different worlds inside the organization,
with distinct languages. SOA is one strategy to unite these “worlds” and
guarantee that they work aligned with each other. We look to demonstrate in
this article the definition of SOA, how it works and its advantages.
Resumo. Tecnologia de Informação e os setores de negócio são partes
essenciais para qualquer organização. Atualmente, vivem em mundos
separados dentro do ambiente empresarial, inclusive com linguagens
distintas. SOA é uma estratégia para unir esses “mundos” e fazer com que
ambos trabalhem de forma alinhada. Procuramos demonstrar neste artigo a
definição de SOA, como funciona e quais são suas vantagens.

1. Definindo SOA – Arquitetura Orientada a Serviços

Uma das definições de SOA, segundo a CIO Briefing, é que é uma metodologia de
desenvolvimento, onde criamos o software através da união de serviços. Os serviços
podem ter quer ser criados ou reutilizados, caso já existam.
Com a abordagem correta de SOA, evitamos redundância no processo de
desenvolvimento da solução, assim atendemos de uma forma mais rápida a necessidade
de todos, não precisamos “reinventar a roda”, apenas criar os serviços uma vez e
consumi-los ao longo do projeto.
Com isso, SOA possibilita que aplicações fragmentadas de varias áreas ou
departamentos possam se integrar e comunicar. Dessa forma também é possível
desenvolver novas aplicações ou gerar modificações de forma mais fácil.
Na arquitetura orientada a serviços existem princípios a serem seguidos,
segundo Thomas Erl, alguns deles são: contrato, acoplamento, abstração, reusabilidade,
autonomia, independência de estado, visibilidade e composição de serviços.
SOA, numa definição de nível mais abstrato, é a arquitetura que permite TI e
negócios conversarem “na mesma língua”, que possibilita o alinhamento de ambos em
prol do mesmo objetivo.
Nós deixamos de reutilizar simplesmente métodos ou funções; Reutilizamos
serviços de alto nível, sem se preocupar com linguagens ou barreiras tecnológicas.

2. Serviços
São os componentes ou funcionalidades que se espera do software. Podem ser
entendidos como partes pequenas do software que podem ser integradas com facilidade
a outros serviços.
 Os serviços são gerados através de um mapeamento dos negócios que o software
abordará. Os gerentes de negócio em conjunto com os de TI devem identificar quais são
os processos importantes naquela determinada área, como eles funcionam e quais são as
boa práticas.
Após essa identificação, os serviços identificados devem ser “traduzidos” em
código de programação. O serviço tem uma interface que descreve oque ele faz e a
forma de se conectar a ele. Com a interface, quem vai consumir o serviço sabe qual é o
a finalidade do serviço, quais informações o serviço necessita e o resultado que ele gera,
sem precisar, necessariamente, saber como a tarefa será cumprida.
Um exemplo de serviço que a CIO Briefing mostra é o envio de uma query para
gerar um relatório de credito de cliente a um site, para saber se o mesmo se adequa ao
empréstimo. Assim, os programadores abstraem a parte relevante e independente do
código para realizar essa consulta e criam um serviço, então, sempre que for necessário
consultar credito, basta invocar esse serviço que estará disponível para todos que for
dada permissão para invocá-lo.

3. Princípios do SOA
Existem alguns princípios que devem ser seguidos para que a abordagem SOA seja
utilizada de forma eficiente e em sua totalidade.

3.1. Contratos e sua padronização

Contratos, segundo Thomas Erl, servem para “expressar o propósito e capacidades de
um serviço de forma consistente”. Isso vale para as pessoas utilizando-os (documentos
descritivos) e também para o momento de consumação do serviço (interface de
comunicação técnica). O contrato deve ser padronizado para o projeto. Se cada
contrato for montado de forma diferente, ocorrerão problemas de identificação ao
catalogar os serviços existentes.

3.2. Baixo acoplamento

O acoplamento pode ser comparado com a dependência existente entre duas ou mais
partes. Níveis altos de acoplamento são prejudiciais, se necessitamos modificar alguma
parte, geramos trabalho extra em outras. Devemos buscar um nível de flexibilidade
dentro dos limites de tempo e custo.

3.3. Abstração do serviço

Os usuários de um serviço devem saber apenas o necessário para sua utilização. Manter
detalhes “escondidos” nos permite modificar o serviço sem nos preocupar com os
detalhes do contrato.
O conceito é simples – divulgue apenas o que for absolutamente necessário –
mas nos leva a questões de projeto complexas. Não se pode expor muita informação
nem pouca, deve-se encontrar o equilíbrio para que o serviço possa ser reutilizado em
seu tempo de vida.
3.4. Reutilização do serviço
Faça um serviço que possa ser usado em mais de uma situação. É o princípio
fundamental para SOA – uma solução genérica pode ser reutilizada pelo projeto inteiro
e mesmo por outros serviços, economizando tempo e dinheiro.

3.5. Autonomia do serviço

Cada serviço de nosso inventário deve ser um bloco independente. Quanto mais um
serviço pode tomar suas decisões sem depender de outros, seguindo sua própria lógica,
mais autônomo ele é.
As principais vantagens da autonomia são aumento o aumento de confiança e
previsibilidade de comportamento do serviço. Podemos dividir a autonomia em dois
tipos, autonomia de execução e de governança.

3.6. Gerenciamento do estado do serviço

Conforme o crescimento do projeto, os serviços têm a carga de dados aumentados e o
tempo de execução prolongado. Quanto mais instâncias do serviço existir, mais
complexo o cenário fica.
Esses serviços, enquanto ativos, possuem um “estado”, dados que devem ser
processados que geram consumo de recursos. Os serviços devem gerenciar seus estados
para permitir o reuso do serviço sem problemas de desempenho.

3.7. Capacidade do serviço de ser descoberto

De nada adianta possuir um serviço se você não sabe que ele existe. Propósito,
capacidade e limitações são metadados essenciais para descobrir se precisaremos criar
um serviço do zero ou simplesmente utilizar o que já existe, reside no contrato do
serviço.
Os serviços devem ter uma descrição apurada e os humanos devem analisar as
informações para a escolha do serviço mais apropriado ou criação de um novo.

3.8. Composições de serviço

Nas organizações encontraremos cada vez problemas mais complexos. Não devemos
simplesmente criar um único serviço igualmente complexo e apresentar como solução.
Um grande problema deve ser dividido em unidades menores, permitindo criar
(ou reutilizar) serviços que os resolvam, e por consequência, resolvam o problema
maior. Os serviços devem ser possíveis de se utilizar em conjunto com outros para
alcançar soluções de cenários complexos.

3.9. Interoperabilidade
Todos os 8 princípios de uma forma ou outra nos levam a interoperabilidade, a
capacidade de nos desprendermos de uma determinada plataforma de desenvolvimento
ou mesmo de utilização. Não importa a linguagem utilizada em cada serviço, nem
onde os serviços serão consumidos, seguindo os princípios, ganhamos implicitamente a
interoperabilidade.
4. Web Service
A Dextra define web service como sendo um componente de software ou uma unidade
logica de aplicação que se comunica por padrões da internet, as funcionalidades desse
componente são implementadas em “caixa preta”, assim esses componentes são
reutilizados sem a preocupação de como foi implementado, eles são acessados por
outras aplicações através de protocolos e formatos de dados padrões.
A WebMobile relata que web service é descrito através de documentos de
definição que são baseados em XML e que esses documentos formam a descrição do
serviço.
Os Web services são padronizados em 3 camadas que são: integração, descrição
e descoberta de acordo com a JSK Consultoria e Treinamento.
A camada de integração contem as informações do processamento físico, onde se
encontra a execução das funções desejadas, também se define os protocolos de
comunicação padronizados como o HTTP ou SOAP. Os protocolos são usados para
transporte dos dados recebidos e enviados de forma transparente pela internet ou redes
corporativas, sem ter o intermédio de softwares ou qualquer artifício técnico.
A camada de descrição tem o objetivo de descrever as funções que o serviço
oferta, as informações de entrada que o serviço precisa para ser executado (interface) e
os resultados que ele gera. Nessa segunda camada também existe a descrição das
funções transacionais e de orquestração ou coordenação, que especificam como o
serviço pode ser usado em um processo de negocio como um todo.
A camada de descoberta permite através de suas definições que os serviços
possam ser encontrados pelos interessados. Existem mais 3 camadas de controle para as
camadas anteriores. A camada de controle de qualidade registra falhas que possam
ocorrer na execução do serviço, e também registra se o tempo de resposta do serviço
para avaliar se esta de acordo com o determinado.
A camada de segurança verifica quem acessa o serviço e registra históricos de
acesso, e a camada de gerenciamento tem a função de monitorar, controlar as
estatísticas, históricos e parâmetros de serviços que são gerados pelas as camadas de
controle de qualidade e segurança. Algumas pessoas confundem SOA com Web
Sevices, porem eles não são iguais.

5. Qual é a diferença entre SOA e Web Services?

SOA é uma arquitetura que visa à construção de sistemas através da combinação de
serviços fracamente acoplados, e Web service é um conjunto de tecnologias que são
baseadas em XML que permitem que aplicações se comuniquem independente da
plataforma. Segunda a IBM, essa diferença pode ser entendida como SOA sendo a
arquitetura e os web services os blocos de construção.
Essa confusão pode ser devido ao grande uso de web service na construção de serviços
em SOA, pois o web services atende com grande eficiência os princípios de SOA para
gerar que os serviços produzam o resultado esperado.

6. Vantagens
As vantagens de se ter uma arquitetura orientada a serviços nos remete a enxergar de
uma maneira mais ampla a empresa em que está sendo implantado este tipo de serviço e
seu porte empresarial, podendo ser que uma empresa com um porte não muito grande e
com poucos sistemas não tenha grandes vantagens em se ter esse tipo de modelo.
Segundo alguns arquitetos ter um bom aplicativo SOA, envolve muito mais
trabalho do que simples integrações de aplicativos e para que este trabalho produza
benefícios aparentes a SOA tem de reduzir trabalho em outros pontos.
Para entender os benefícios gerais empregados pela SOA, há dois níveis a serem
examinados como: as vantagens do desenvolvimento orientado a serviços e em segundo
lugar as vantagens de uma estratégia SOA.

6.1. Vantagens do Desenvolvimento Orientado a Serviço

Umas das vantagens apresentadas pela SOA é a reutilização de software, novos ou já
desenvolvidos a partir de aplicações já existentes, obtendo-se um esforço menor a partir
do que já foi desenvolvido e será reutilizado. SOA faz a integração dos aplicativos de
forma mais rápida consequentemente reduzindo custos e prazos, oferecendo
flexibilidade e agilidade de resposta às empresas.
Empresas que adotaram essa reutilização também adotaram a metodologia da
Governança para poder aumentar as chances de reutilização de software, pesquisas
apontam que os serviços são reutilizados em cerca de 10% a 40% dos casos.
Outra vantagem de usar SOA é o aumento da produtividade, com a reutilização
dos serviços os processos em desenvolvimento andam mais rápido, podendo a equipe de
desenvolvimento trabalhar em outros projetos, tornando a integração mais rápida e com
menos custos.
Maior agilidade, agregando valores para facilitar a modificação dos sistemas,
fazendo com que aplicativos redundantes deixem de existir, dividindo-se os processos
em pequenos serviços isolando-os para que possam ser modificados conforme sua
necessidade reagindo da melhor forma aos picos de atividades e transferindo capacidade
para um serviço especifico.

6.2. Vantagem de uma estratégia SOA

SOA é a visão geral dos processos de negocio das empresas, fazendo com que os
desenvolvedores visualizem a empresa de uma maneira tecnológica, fazendo com que a
necessidade de desenvolver versões únicas que possam ser usadas por todos, uma
maneira de entender e fazer com que os processos possam ter sua capacidade total usada
facilitando consequentemente os processos das empresas.
O livro SOA para leigos, 2º edição, defende mais algumas vantagens:

6.3. Melhor qualidade de serviço

A estrutura empregada nos dá previsibilidade e regularidade entre regras de negócio,
políticas e os serviços do software. Ganhamos estabilidade e certeza, pois sabemos
facilmente quais são as regras e políticas que cada serviço codificado implementa.
6.4. Cumprindo com regulamentações de governança
Cumprir com requisitos não funcionais também se torna mais fácil. Seguir os
regulamentos e diretrizes de qualidade que uma organização pode ter é um subproduto
natural de SOA.

6.5. União entre TI e negócios

A relação entre a equipe de TI e a área de negócios poderia ser vista como uma questão
de “anotações de pedido”. Com as aplicações ganhando cada vez mais importância, é
necessário que ambos trabalhem juntos.

7. Conclusão
SOA apresenta uma metodologia promissora, não sendo apenas uma “tecnologia” nova,
mas sim toda uma plataforma de apoio para o sucesso de desenvolvimento empresarial,
usando de tecnologias que já existem no mercado há algum tempo.
Reutilização de trabalho, WebServices e interoperabilidade não são palavras
novas no dialeto da TI, o diferencial é como SOA os une e utiliza. Empresas como IBM
e Microsoft já utilizam esta nova abordagem, nomes fortes que só tendem a impulsionar
mais o seu crescimento.

Referências
Thomas Erl, “SOA Principles of Service Design”, Prentice Hall, 2007.
Judith Hurwitz, Robin Bloor, Marcia Kaufman, Fern Halper, “Arquitetura Orientada a
Serviços – SOA para Leigos”, Alta Books, 2009.
CIO Briefing, “O Tsunami SOA – Relatório especial para líderes corporativos”, 2006.
Vitor Fernando Pamploma, “Web Services – Construindo, disponibilizando e acessando
Web Services via J2SE e J2ME”, 2010.: http://javafree.uol.com.br/artigo/871485/,
visualizado em 01 de novembro de 2010.
Accenture, “Service-Oriented Archutecture: Business Benefits”, Março de 2010.
http://www.accenture.com/Global/Technology/Service_oriented_Architecture/Servic
eOrientedBenefits.htm, visualizado em 03 de Novembro de 2010.
JSK Consultoria e Treinamento “Web Services”,
http://www.jsk.com.br/webservices.html, visualizado em 01 de novembro de 2010.
Revista WebMobile “Introdução às tecnologias Web Services: SOA, SOAP, WSDL e
UDDI - Parte1”, http://www.devmedia.com.br/post-2855-Revista-WebMobile-
Edicao-1.html, visualizado em 01 de novembro de 2010.
Dextra “Web Services na Integração de Sistemas Corporativos”,
http://www.dextra.com.br/empresa/artigos/webservices.htm, visualizado em 01 de
novembro de 2010.
IBM, “Por dentro da SOA”, http://www-
01.ibm.com/software/br/info/features/futureenterprise/, visualizado em 28 de outubro
de 2010.