Prof. Wamberg Oliveira
2/37
Introdução





Desenvolver software foi e continuará sendo difícil, pois nem tudo que
queremos pode ser feito
Num ambiente operacional tradicional é difícil fazer a integração de
softwares, já que as regras de negócio são dinâmicas e podem sofrer
alterações a qualquer momento, e a área de TI deve estar preparada para
assimilar essas mudanças e gerar resultados corretos e em tempo hábil.
As empresas por muito tempo têm procurado integrar sistemas existentes
para dar suporte de TI para os processos de negócio atuais e para os
futuros processos a serem implantados
Uma arquitetura padrão e flexível se faz necessária para dar suporte a
esse processo.
SOA (Arquitetura orientada a serviços) aparece no mercado como uma
possível solução para esta problemática
3/37
Introdução




Unifica os processos de negócio estruturando grandes aplicações como
uma grande coleção de pequenos módulos chamados serviços.
Essas aplicações podem ser usadas por diferentes grupos de pessoas da
empresa, e novas aplicações podem ser construídas a partir da
combinação destes serviços.
Umas das grandes promessas da SOA é o que o custo marginal para
produzir uma nova aplicação é quase zero, já que existem serviços já
prontos e basta combinar os serviços para ter uma nova aplicação.
Segundo prognósticos do Instituto Gartner, com 70% de probabilidade,
até o final de 2008, a SOA será a prática de engenharia de software
predominante, dando fim a 40 anos de dominação de arquiteturas
monolíticas de softwares
4/37
Definições





O termo "Service-Oriented Architecture" (SOA), ou ainda em português
Arquitetura Orientada a Serviços, é um novo modelo de negócios que visa
organizar os recursos de software, também conhecidos como serviços, de
forma que estes possam compor os processos de negócio, atendendo
assim às necessidades da empresa.
Mas para entender o que é o SOA, é necessário ter em mente o conceito
de serviço, tão utilizado no mundo da TI.
O serviço é a lógica do negócio (servidor), capaz de ser acessado por
outro processo (cliente). O serviço, no ponto de vista da arquitetura SOA,
é uma função de negócio que implementa os processos de negócio,
possuem interface bem definida, baseada em padrões abertos.
Além disso, possui a característica de poder ser disponibilizado e
reutilizado em outros sistemas.
A maneira mais comum de implementar a SOA é através de Web services,
que são soluções utilizadas na integração de sistemas e na comunicação
entre aplicações diferentes .
5/37
SOA X OO




A Arquitetura Orientada a Serviços é um paradigma utilizado no
desenvolvimento de softwares, a exemplo da Orientação a Objetos (OO).
Por esse motivo, a SOA muitas vezes é confundida com a OO, mas o que
ocorre é que os princípios da primeira derivaram em grande parte dos da
segunda.
Quando de sua idealização, a OO foi considerada por muitos como uma
solução definitiva no processo de desenvolvimento de software; porém,
problemas não previstos anteriormente na orientação a objetos puderam
ser elucidados com os novos recursos oferecidos pela orientação a
serviços.
Desta forma, como ocorreu com a OO, é de se imaginar que, futuramente,
um outro paradigma, ainda mais completo poderá complementar ou
mesmo suplantar a SOA em sua totalidade.
6/37
Características desejáveis


Para que uma arquitetura seja considera como orientada a serviços, ela deve
apresentar uma série de características que a norteiem desde sua fase de
desenvolvimento até a etapa de uso, bem como sua manutenção
Principais características

Reusabilidade
 A reusabilidade é um fator importante dentro contexto da SOA, pois sendo
aplicada de forma eficiente, evita gastos exorbitantes e desnecessários
para as indústrias de software. Assim, tempo e verba que antes seriam
destinados à realização de novas tarefas podem ser realocados para outras
atividades, aproveitando-se as soluções elaboradas para situações já
ocorridas.

Baixo Acoplamento
 As funções de negócio (atividades) em SOA são implementadas na forma
de serviços que não dependem de outros componentes para que
funcionem normalmente, e que podem ser utilizados diversas vezes no
sistema.Estes serviços são conhecidos como componentes independentes,
que interagem entre si apenas por intermédio de interfaces bastante
definidas.
7/37
Características desejáveis

Principais características

Neutralidade de implementação
 Essa característica denota que não existem limites a serem estabelecidos
em relação ao conjunto de ferramentas (tecnologias, linguagens,
plataformas) a serem utilizadas na forma de implementação em SOA.
 Com a implementação de serviços, outros desenvolvedores podem usufruir
destes de forma adequada, de acordo com a interface que for
especificada. Mas para isso, é importante que a função do serviço seja
especificada, juntamente com informações do tipo dados de entrada e de
saída (E/S). Informações mais detalhadas acerca da implementação de um
serviço não possuem relevância para o resto do sistema, e, por isso não
deverão ser disponibilizadas.
8/37
Características desejáveis

Principais características

Interoperabilidade
 O desenvolvedor, ao implementar um serviço, deve especificar a função de
serviço, assim como demais dados pertinentes de E/S. Para que isso
ocorra, uma série de padrões e regras devem ser observados, e estes, por
sua vez, foram desenvolvidos para listar todos os requisitos importantes
para que um serviço seja utilizado e acessado de forma viável através de
uma rede.
 Com isso, notamos que a arquitetura proporciona grande liberdade de
desenvolvimento, e daí se chega à abordagem da interoperabilidade,
que pode ser definida como a capacidade do SOA de se comunicar de
forma o mais transparente possível com outro sistema, estabelecendo uma
coexistência que independe de padrões ou indústrias de tecnologia.
 Desta forma, a importância deste princípio se dá porque ele proporciona a
idealização e concretização de soluções de maior qualidade e flexibilidade,
visto que são minadas eventuais dificuldades de comunicação entre
sistemas diversos, onde cada um, por sua vez, foi implementado a partir
de situações, limitações e necessidades também bastante diferentes.
9/37
Características desejáveis

Principais características

Modularidade
 Em SOA, a modularidade é a característica do sistema que permite que ele
seja composto de várias partes – ou módulos – distribuídas em diferentes
plataformas e ambientes, o que permite que se agregue soluções de alta
escalabilidade e baixo custo.
 Ela promove, assim, um alto nível de separação entre os componentes da
infra-estrutura e os da lógica de negócio, bem como uma maior
independência no desenvolvimento dos componentes de negócio,
corroborando ainda para a promoção da reusabilidade.
 Por não possuírem forte dependência entre si, os módulos podem ser
desenvolvidos, implantados e atualizados de forma independente.
10/37
Relembrar é viver
11/37
SOA: Uma abordagem para
alinhar Negócios/TI

Uma abordagem diferente para arquiteturas de TI de corporações
... direcionada para negócios, não para tecnologia
... focada no compartilhamento e reuso de funcionalidades
... alinhando negócios e TI
... confiando na governança
... pode ser implementada usando qualquer tipo de arquitetura, tecnologia
ou conjunto de produtos
12/37
Arquitetura SOA
13/37
Arquitetura SOA



Camada Corporativa
 Camada responsável por identificar e gerenciar os negócios aos quais
se deseja tratar com a aplicação SOA.
Camada de Processos
 Camada que identifica e caracteriza os processos dos negócios
definidos na camada acima.
 Cada processo é único em uma determinada área funcional, podendo
ser dividido em sub-processos, que podem também ser subdivididos,
exibindo as dependências funcionais de um processo.
 Difere de um serviço pelo fato de que um serviço deve ser reutilizável
em diversos contextos, enquanto um processo é único em seu
contexto.
Camada de Serviços:
 Camada que mapeia os serviços disponíveis na aplicação, provendo
funcionalidades básicas, técnicas e/ou de negócio.
14/37
Arquitetura SOA


Camada de Componentes
 Camada que mapeia os componentes que podem ser “promovidos a
serviços”, pela avaliação da capacidade dos componentes serem
reutilizáveis em outros sistemas.
 Um serviço pode ser composto de diversos componentes, sendo estes
também utilizáveis em serviços distintos.
Camada de Objetos
 Identifica e caracteriza os objetos, que são utilizados no sistema. SOA
estende o conceito de POO quando exige que um objeto além de ser
público, possa ser importante para o sistema ao ponto de ser
encapsulada como um componente, sendo em seguida incorporada a
um ou mais serviços do sistema.
15/37
Arquitetura SOA- Exemplo
Arquitetura SOA- Exemplo





Neste gerenciador de planos de saúde – representando a camada
corporativa –, é composta de dois processos, renovar conta (1) e
processar seguro de vida (2).
Os processos se utilizam de alguns serviços, sendo alguns deles utilizados
por ambos os processos, exemplificando sua característica de reutilização.
A camada de legado – representando a camada de componentes –, exibe
coleções de objetos – as figuras menores – que são encapsulados para
utilização na camada de serviços.
Por exemplo, o processo 2 utiliza, entre outros serviços, o serviço
Configurar Benefícios.
Este serviço é composto de objetos que pertencem aos seguintes
componentes: Sistema de Gerenciamento de benefícios, Banco de Dados
de Clientes e Parceiros de Negócio.
17/37
Aplicações SOA

Apache Tuscany

Integrante do projeto Apache, o Tuscany é um framework de desenvolvimento
de aplicações sob a arquitetura SOA. O projeto está conforme com as
especificações do grupo OpenSCA, e é dividido em três componentes:
 SCA: Service Component Architecture - Arquitetura que define como criar
componentes e como interliga-los para criar aplicações baseadas em
serviços. Uma característica do SCA é que estes componentes não
precisam necessariamente ser criados numa mesma linguagem ou
tecnologia.
 DAS: Data Access Service – Serviço responsável por simplificar a
manipulação de dados, que podem ser desde aplicações que usam JDBC
até comunicações de XML/HTTP, usado pelos Web Services, tornando
simples a manutenção para o desenvolvedor.
 SDO: Service Data Object: Framework que unifica o modelo de
programação entre vários tipos de dados, fazendo com que possa ser
utilizado mesmo modelo de lógica, programação e API, independente do
tipo de dados acessados – estruturados, semi-estruturados, nãoestruturados.
18/37
Web Services




Uma das aplicações mais difundidas que utilizam SOA são os web services.
Conceitualmente, Um web service é uma arquitetura de criação de serviços, que
são distribuídos através de uma rede, mais comumente a internet.
Através do web service, os serviços podem ser reutilizados na rede por outros
sistemas, sem qualquer tipo de intervenção direta dos usuários.
A comunicação entre clientes/servidores acontece através de mensagens sob o
protocolo XML.
Podemos destacar como vantagens do Web Service:

Interface abstrata: Usado para ocultar do usuário os detalhes de
implementação;

Dados com semântica: Além dos dados, os metadados a eles associados
também são transmitidos;

Portabiliadade: O uso de XML permite que a portabilidade do sistema seja
feitas em vários tipos de aplicação;

Segurança: Deve-se a possibilidade de criptografia dos dados trafegados;

Uso responsável de recursos: Os recursos utilizados não são consumidos em
estado de espera.
19/37
Web Services

A arquitetura dos Web Services é baseada na interação de três entidades: o
Provedor de Serviços, o Solicitante de Serviços e a Agência de Descobrimento.
Estas entidades se comunicam através de operações de publicação, pesquisa e
ligação
20/37
Web Services



Provedor de serviços: entidade que cria o Web Service, disponibiliza o serviço
para que qualquer elemento da rede possa utiliza-lo. Isso é feito através da
descrição do Web Service em um formato padrão, tanto para quem desejar usar o
serviço quanto para hospedagem em um registro central, a Agência de
Descobrimento (AD).
Solicitantes de serviços: entidade que deseja consumir algum serviço
compartilhado por algum provedor de serviço. Isso é possível a partir da descrição
disponibilizada pelo provedor de serviços, recuperando os seus detalhes através de
uma pesquisa sobre o registro publicado.
Agência de Descobrimento: Localização central onde o provedor de serviços
pode relacionar seus Web Services, e no qual um consumidor de serviços pode
pesquisá-los.
21/37
Web Services

A arquitetura de um Web Service também é definida pelos protocolos que são
utilizados para a realização da comunicação de dados e metadados entre
solicitante e provedor de serviços. Esta pilha descreve os grupos de padrões que
compõem a pilha de componentes do Web Service.
22/37
Web Services



HTTP:

Protocolo de Transporte utilizado para transmitir requisições na Web, baseado
em requisições de clientes e respostas dos servidores;
SOAP:

Simple Object Access Protocol – Protocolo responsável pela troca de
mensagens entre os atores do Web Service. É composto de duas partes
principais: uma que determina o framework de transporte de mensagens, que
pode usar qualquer protocolo de transporte, mais comumente o HTTP; a outra
é subdividida em: conjunto de regras para definição de tipos de dados,
convenção para uso de RPC e conjunto de regras para uso do SOAP com
protocolos de transporte, como o HTTP.
XML:

Extensible Markup Language – Linguagem de representação de dados semiestruturados, o mais recomendável para o transporte dos dados através dos
atores do Web Service. Para a descrição dos tipos de dados, são utilizados XML
Schemas.
23/37
Web Services

WSDL:


Webservice Descriptor Language – Sistema de descrição de serviços. Nada
mais é do que um documento XML em que são descritos os serviços
disponibilizados pelo Web Service, independente de sua arquitetura ou
linguagem de programação, ou seja, descreve um conjunto de mensagens
SOAP e como elas serão utilizadas pela aplicação que usa o Web Service.
UDDI: Universal Description, Discovery and Integration –

especificação utilizada para a descrição, integração e descoberta de Web
Services. [4] descreve o protocolo UDDI como uma lista telefônica, sendo que
as “páginas brancas” representam as informações do Provedor de Serviços –
como nome, endereço, telefone –, as “páginas amarelas” representam as
categorias de serviços classificadas em taxonomias padrões – como um
agrupamento de empresas de uma mesma categoria – e as “página verdes”
representam a interface para acessar o serviço, com detalhamento suficiente
para uso no desenvolvimento de uma aplicação que utilize Web Services –
como um catálogo de serviços oferecido pro uma empresa.
24/37
Vantagens do SOA


O SOA oferece uma série de benefícios para entidade que fará uso do mesmo.
Características como baixo acoplamento, neutralidade de implementação e
reusabilidade de funções de negócio, fazem com que o SOA permita
Maior flexibilidade e adaptação




O alto nível de flexibilidade e a habilidade de se adaptar rapidamente às mudanças nos requisitos
são, consideradas por muitos, como as maiores vantagens do SOA.
Segundo a arquitetura tradicional, a cada mudança em regras de negócio, vários sistemas legados
deveriam ser modificados para satisfazer a mudança.
Com o SOA, basta alterar a implementação no serviço correspondente, pois o mesmo é usado por
vários processos que, após esta modificação, estarão alinhados à mudança.
Interoperabilidade




O uso de padrões torna possível a concretização de uma grande vantagem no SOA: a
interoperabilidade entre sistemas.
Na arquitetura tradicional, a integração entre ambientes heterogêneos necessitava o desenvolvimento
de ferramentas para permitir e garantir a comunicação entre os ambientes. Geralmente, a solução era
muito específica, vulnerável à mudanças e demandava alto custo.
Com SOA, a interoperabilidade no sistema é feita basicamente aplicando-se coerentemente os
padrões de design adotados.
Como exemplo disso, uma aplicação JAVA pode se comunicar com um sistema Delphi na rede,
bastando que ambos tenham implementado os padrões necessários.
25/37
Vantagens do SOA

Diminuição de custos de Manutenção



Reuso de Código





Outra clara vantagem do SOA é a diminuição dos custos de manutenção. Antes se uma falha lógica de
uma função fosse detectada ou se a mesma tivesse de ser alterada devido a mudanças nas regras de
negócio, seria necessário alterar em todas as partes do sistema onde a função estivesse presente.
Com o SOA, basta alterar o serviço correspondente à funcionalidade, reduzindo assim o custo e a
complexidade das tarefas de manutenção.
Em sua arquitetura, o SOA prega o encapsulamento das funcionalidades dos sistemas legados em
serviços, de tal forma que se possa fazer usos destes serviços em qualquer processo de negócio.
Sendo assim, o reuso de código acaba sendo uma consequência dos paradigmas do SOA.
Além destas vantagens, existe uma grande vantagem administrativa para as
entidades.
Arquiteturas baseadas no SOA facilitam o gerenciamento do crescimento dos
sistemas corporativos, provendo alto nível de escalabilidade ao arquiteto, podendo
diminuir drasticamente o nível de complexidade do sistema, diminuindo assim os
custos com o mesmo.
Apesar das vantagens aqui citadas, a implantação do SOA ainda é um processo lento
e relativamente custoso, o que é uma visível desvantagem de se implantar o SOA.
26/37
Padrões SOA



Para facilitar e otimizar o desenvolvimento de aplicações em qualquer tipo de
arquitetura, são criados padrões de projeto, que são porções de código com boas
práticas para resolução de problemas específicos que ocorrem com freqüência,
sendo disponibilizados e validados pela comunidade.
Com o padrão SOA, foi mobilizado no site SOA Patterns alguns padrões específicos
criados por grupos de pesquisa e comunidade em geral para auxiliar o
desenvolvimento de aplicações sob o padrão orientado a serviços.
A especificação disponibilizada pelo site SOA Patterns divide os padrões SOA em
categorias:

Padrões de Projeto de Linguagem Básico para Inventário de Serviços;

Padrões de Projeto Arquiteturais;

Padrões de Projeto de Linguagem Básico para Serviços;

Padrões de Projeto de Serviços;

Padrões de Projeto de Componentes Comuns.
27/37
Padrões SOA


Um exemplo com semelhanças em uma abordagem orientada a objeto, é o Padrão
Service Facade, da classe de Projeto de Serviços.
Assim como numa abordagem orientada a objeto, o Facade serve para “ocultar” de
outros processos – consumidores de serviços – a especificação do serviço,
oferecendo a possibilidade de modificação do serviço sem impactar nos
consumidores.
28/37
SOA e Mercado






Aos poucos o mercado começa notar a atuação de SOA nos negócios. Isso porque,
quem utiliza SOA consegue oferecer novos serviços rapidamente, o que pode
acontecer por meio de sistemas de TI novos ou existentes.
Uma pesquisa feita nos Estados Unidos pelas revistas CIO e Computerworld
identificou que 58% dos 612 executivos de TI entrevistados implementou o conceito
ou pretendem implantar o SOA a curto prazo.
Aproximadamente 44% deles utilizarão SOA para integrar aplicações internamente,
28% para fornecer serviços a clientes ou consumidores e 21% para se conectarem
com aplicações externas fornecidas por parceiros.
Uma pesquisa feita em Portugal pela IDC analisou que será o mercado de TI no
período entre 2005 e 2009.
O resultado mostrou que mais da metade dos investimentos será direcionada para
hardware, seguido de serviços e softwares.
A estimativa também é que haja um aparecimento cada vez maior de tecnologias e
ferramentas de desenvolvimento orientadas para a implementação de soluções SOA.
29/37
SOA e Mercado






Aos poucos o mercado começa notar a atuação de SOA nos negócios. Isso porque,
quem utiliza SOA consegue oferecer novos serviços rapidamente, o que pode
acontecer por meio de sistemas de TI novos ou existentes.
Uma pesquisa feita nos Estados Unidos pelas revistas CIO e Computerworld
identificou que 58% dos 612 executivos de TI entrevistados implementou o conceito
ou pretendem implantar o SOA a curto prazo.
Aproximadamente 44% deles utilizarão SOA para integrar aplicações internamente,
28% para fornecer serviços a clientes ou consumidores e 21% para se conectarem
com aplicações externas fornecidas por parceiros.
Uma pesquisa feita em Portugal pela IDC analisou que será o mercado de TI no
período entre 2005 e 2009.
O resultado mostrou que mais da metade dos investimentos será direcionada para
hardware, seguido de serviços e softwares.
A estimativa também é que haja um aparecimento cada vez maior de tecnologias e
ferramentas de desenvolvimento orientadas para a implementação de soluções SOA.
30/37
SOA e Mercado


Porém, vale ressaltar que a adoção desse tipo de arquitetura é um processo que
deve acontecer em longo prazo, principalmente porque, para que as organizações
concretizem o conceito na realidade corporativa, será preciso uma série de
providências que vão desde a preparação tecnológica e pessoal até o nível de
consolidação dos sistemas.
Pode-se notar que o mercado está adotando o SOA, porém, de uma forma ainda
receosa, progressiva e controlada a fim de evitar transtornos nos sistemas de
informação das empresas.
31/37
32/37