Aula 01 PDF

Analista de Sistemas Terracap
Curso de Engenharia de Software

Prof. Diego Carvalho Aula 01
RQ TURA ORIENTADA A SERVIOS (SOA)
Nesse momento da aula, vamos falar sobre Service Oriented Architecture (SOA)!
Antes de adentrarmos nesse tema, importante que vocs compreendam os
conceitos de arquitetura e de servio. No contexto de engenharia de software, a
arquitetura a rganizao u estrutura dos mponentes significativos do
sistema de software que interagem por meio de interfaces. Simples, no ?
J um servio um mecanismo que permite acessar um conjunto de recursos, no

qual o acesso fornecido por meio de uma interface descrita e exercitada
consistentemente de acordo com restries e polticas especificadas pela descrio
do servio. oferecido or ma ntidade (Provedor e Servios) ara uso de
terceiros (Consumidor e Servios), mas h um detalhe!
No necessidade de sses terceiros conhecerem o provedor de servios,

podendo nclusive fazer so o servio de forma a extrapolar po riginal
concebido elo rovedor. Alis, importante salientar que esses servios so
agnsticos! Como , professor? religio? No, esse o termo utilizado para
demonstrar que a lgica de um servio no depende de outras partes.
De acordo com Thomas Erl:
Dentro de uma soluo orientada a servios, as unidades de lgica (servios)

encapsulam funcionalidades specficas nenhum aplicativo ou processo
de gcio. Esses servios so classificados como ativos de tecnologia da
informao agnsticos e reusveis. Servios agnsticos fornecem um intervalo
de funcionalidades genricas. Qualquer servio agnstico pode, portanto, ser
adaptado inmeras vezes para que seja possvel automatizar diferentes
processos de negcio como parte de diferentes solues orientadas a servios.
Um servio agnstico quando ua lgica ndependente ocessos
negcio, icativos u tecnologias roprietrias. Quanto mais agnstico for
um servio, mais genricas so suas capacidades. Portanto, servios agnsticos
tm maior potencial de reso".
Galera, basta pensar em qualquer empresa de prestao de servio. Existe um

provedor ue fornece algum ipo e servio o nsumidor que consome o ervio
fornecido. Eu, por exemplo, contrato uma empresa e pago por um servio de
Prof. Diego Carvalho www.estrategiaconcursos.com.br Pg. 3 de 162

muito importante visualizar e posicionar a Arquitetura Orientada a Servios como

um odelo de arquitetura que agnstico qualquer lataforma e tecnologia.
Ao fazer isso, uma empresa tem a liberdade para perseguir continuamente os
objetivos estratgicos associados computao orientada a servios, aproveitando
os avanos tecnolgicos futuros.
No ercado ual, plataforma de tecnologia mais sociada com realizao e

Arquitetura Orientada a Servios o s ervices. Claro, existem tambm outras
tecnologias, tais como: DCOM, CORBA, RPC, DDS, WCF, etc. Todas elas podem
ajudar a implementar a arquitetura orientada a servios, na medida em que essa
arquitetura uma abordagem, um paradigma, uma forma de organizao.

Vocs j viram o tamanho de um banco? Joo no o nico que quer melhorar sua
eficincia. Multipliquem a situao or gumas ntenas s eremos ma
2
Arquitetura de Bola de Pelo Hairball chitecture) . Em outras palavras, temos
centenas de pelos indo e voltando em tudo que direo. Ningum tem controle
e ningum consegue rastrear absolutamente nada.
Imaginem gora que ns emos ue substituir ma aplicao mensa do anco

porque ela desatualizada e o rnecedor isse que, ois s, parar
de oferecer suporte. Ningum sabe quais aplicaes dependem dessa aplicao.
uma rede sem fim de dependncias que foram criadas uma de cada vez, todas
fazendo sentido no momento de sua criao, mas que ficou catica com o tempo.
2
Alguns chamam de Spaghetti-Like Architecture, i.e., Arquitetura de Macarronada.

servios, so consumidores de servio. A descrio permite que consumidores

prospectivos decidam se o servio conveniente para suas necessidades e
estabelece quando um consumidor satisfaz os requisitos do provedor de servio.
O Modelo de Referncia do SOA, como suporte s dinmicas da interao com

servios, apresenta um conjunto de conceitos que se referem aos prprios servios:
Descries do ervio, ontexto e Execuo, os ontratos Polticas que esto
relacionados s ervios aos eus articipantes. Vamos ver em um pouco mais
de detalhes cada um deles.
A Descrio do ervio epresenta a informao ecessria para utilizar m servio.

O propsito facilitar interao e visibilidade, particularmente quando participantes
esto em domnios proprietrios diferentes. Pelo oferecimento da descrio, ela
torna possvel que potenciais participantes construam sistemas que usam servios e
at mesmo ofeream servios compatveis.
Uma poltica representa alguma restrio ou condio sobre o uso, distribuio ou

descrio de uma entidade prpria definida por qualquer participante. Um contrato,
por outro lado, representa um acordo de duas ou mais partes. Assim mo
polticas, rdos o ambm obre as ndies de uso e um ervio; ele pode
tambm restringir os efeitos esperados no mundo real ao usar o servio.
O Contexto de Execuo de uma interao de servio o conjunto de elementos

de infraestrutura, entidades de processo, afirmaes e acordos de polticas que so
identificados como parte de uma interao de servio. Forma-se, to, m
caminho tre aqueles que possuem ecessidades e aqueles que possuem
competncias. Em suma...
Descrio do ervio um njunto e informaes necessrios para utilizar m

servio, ac litando interao a visibilidade; Contratos e Polticas so restries
ou condies de uso de um servio. Formando um conjunto de regras entre os
participantes; Contexto de Execuo um caminho estabelecido entre os
participantes, constitudo por participantes, infraestrutura, entidades, etc.

Esse registro de servios geralmente contm m epositrio e servios sociado

a duas nterfaces e acesso: uma interface de publicao que serve aos prestadores
de servios e uma interface de consulta que serve solicitantes de servios. Dessa
forma, um solicitante de servios consulta o registro de servios por um servio de
interesse e obtm a localizao do prestador correspondente.
O olicitante de servio, to, e conecta ao restador de servio, emotamente

invoca o ervio o restador. Se um solicitante de servio estiver ciente de um
prestador de servio apropriado, ele j pode decidir se conectar diretamente ao
prestador de servio sem sequer consultar o registro de servios. A vantagem do
registro que se pode procurar e descobrir servios apropriados.
Existem dois odelos bastante similares que implementam odelo riangular m

algumas articularidades. O primeiro o Modelo Publish-Find-Bind, formado pelo
prestador de servios, solicitante de servios e o registro de servios aqui chamado
de Broker de Servios. O segundo o Modelo Find-Bind-Execute3, formado pelo
prestador de servios, solicitante de servios e o registro de servios.
Esse ltimo modelo funciona assim: prestadores de servios publicam servios no

registro de servio; consumidores de servios realizam uma busca por algum servio
3
Alguns chamam de Find-Bind-Invoke.

Recentemente, algumas questes comearam a cobrar tambm a modelagem de

servio. A primeira etapa na implantao de uma soluo orientada a servio est
relacionada a modelagem do servio. So esponsveis or dentificar os ecursos
necessrios ara a construo, econdicionamento u eso e servios xistentes
e a integrao da soluo final.
Normalmente, sa-se as bordagens op-down bottom-up o rocesso e

modelagem. A modelagem Top-Down determina que a organizao identifique,
primeiramente, os processos que considerar prioritrios. J a modelagem bottom-
up determina que a organizao identifique, primeiramente, os processos menos
prioritrios. Bacana?

Pessoal, esse um princpio muito tranquilo! e se esperar que um ervio seja

reutilizvel, .e., osso tiliz-lo iferentes contextos tecnologias. Como
servios contm e expressam lgicas, eles podem ser definidos como recursos da
organizao. Esse princpio fundamental para aumentar a agilidade do
desenvolvimento das aplicaes.
evidente que ser necessrio mais esforo para construir um servio mais genrico
que atenda diversas demandas diferentes, abrangendo vrios cenrios. Observem
tambm ue esse rincpio uma consequncia o rincpio o aixo
Acoplamento. Para que os servios sejam reusados, os contratos de servios devem
ter as informaes necessrias e bem claras sobre as suas capacidades.
Um ervio eutilizvel aquele que no a rega particularidades cnicas de uma

implementao ou egra de negcio ecfica e genrico uficiente para
atender utros rojetos. Fazer um servio bastante reutilizvel um investimento
de mdio prazo e que demanda tempo e dinheiro, e muitas vezes os investidores
no enxergam a sua verdadeira e fundamental importncia.
Estrategicamente, ele capaz promover um maior retorno sobre o investimento ao

construir componentes de mltiplos propsitos, modelando servios agnsticos,
permitindo a criao de inventrios de servios com alta porcentagem de servios
neutros. Os bjetivos or rs a capacidade de reso e servio o diretamente
associados a alguns objetivos ais estratgicos da organizao.
Autonomia e Servios Service Autonomy):
O que autonomia? a capacidade de um servio se auto-administrar. Um servio

autnomo aquele que independe de um elemento externo para executar sua
lgica! Einh? Como , professor? Vamos ensar, or plo, o biente de
execuo o servio! A autonomia de servios um princpio que visa fornecer
servios com independncia de seu ambiente de execuo.
E qual a consequncia disso? Maior confiabilidade, na medida em que os servios

podem operar com menos dependncia de recursos sobre os quais h pouco ou
nenhum controle a longevidade de um ervio bastante dependente de sua
confiabilidade. Se o servio no depende de algum elemento externo para executar
suas atividades, ento ele mais seguro, confivel e autnomo.
O o e se autogovernar ou onomia e servio ode trazer guns enefcios

claros mo, or mplo, o esempenho. Tendo em vista que, dessa forma, se ter

o mnimo de dependncias com outros servios e as execues das funcionalidades

se tornam mais diretas e consequentemente o nmero de erros inesperados diminui
consideravelmente.
Essa autonomia edida e disponibilizada nos ontratos rmais, endo mo

finalidade esclarecer o vel de independncia os eus consumidores. Alm da
maior confiabilidade, a autonomia promove melhor desempenho e previsibilidade
comportamental. Alm disso, como dissemos, ele aumenta a quantidade de
controle que um servio tem sobre o ambiente em tempo de execuo.
Independncia de Estados e Servios (Service Statelessness)
Servios so xplicitamente projetados ara minimizar o erodo urante o ual e

existem m ma condio e dependncia e informaes de estado. A
independncia de estado quando um servio no precisa reter nenhum dado do
estado para que outro servio processe a sua lgica. Podemos citar como exemplo,
o uso do protocolo HTTP.
Ele monta seu cabealho e todo o contedo da pgina que enviada para o
navegador, retornando uma condio e independncia e estado que ele
no etm enhuma solicitao u emria adicional o avegador. Servios so
projetados para minimizar o perodo durante o qual eles existem em uma condio
de dependncia de informao de estado, aumentando a escalabilidade do servio.
Os ervios evem itar alocao de recursos or uito empo! omenda-se

a construo e servios stateless (sem ado). Galera, sso o muito l e
alcanar! A otimizao da alocao de recursos difcil por conta da natureza
distribuda e autnoma dos servios, alm da natureza de mudanas constantes dos
ambientes que utilizam essa arquitetura.
Visibilidade de Servios Service Discoverability):
O termo em ingls discoverability! Como esse vocbulo no existe, traduziram

como visibilidade. Ns j vimos que servios so bastante reutilizveis, mas para que
voc possa reutiliz-lo, voc deve ser capaz de encontr-lo. Servios so rojetados
para erem etivamente descobertos interpretados ara ue, a escoberta, seu
propsito e capacidades sejam claramente entendidos.
O objetivo principal fazer m que o servio e torne visvel a todos, entando

assim agilidade, produtividade e a onfiabilidade dos onsumidores. Os servios

so projetados para que sejam encontrados e seus propsitos e capacidades sejam

claramente entendidos, ou seja, os contratos de servios devem ter meta-
informaes extras que transmitem claramente o que o servio realmente faz.
A aplicao desse princpio aps a implantao de um servio pode comprometer

a qualidade da sua visibilidade, portanto uma boa prtica adicionar as meta-
informaes antes do lanamento da verso inicial. O ecanismo e descoberta
necessrio ara evitar o esenvolvimento edundante de uma soluo ue j s
contida em um servio existente.
Composio de Servios (Service Composability):
Servios o projetados ara que atuem mo articipantes e icazes de uma

composio, ndependente o amanho da complexidade de composio. Ao
discutir os objetivos da composio de servios, boa parte dos objetivos de reso
de servios tambm aplicvel. Isso ocorre porque, muitas vezes, a composio de
servios uma forma de reso de servios.
Talvez voc e lembre que um os bjetivos ue selecionamos ara o princpio a

reusabilidade a possibilitar composio de servios arga escala. A
composio de servios permite que as capacidades de um servio sejam
combinadas vrias vezes com as de outros servios em novas configuraes a fim
de resolver problemas diferentes.
Vamos ver um exemplo? Os rreios isponibilizam m servio al ue, dado m

CEP, etorna um dereo. Eles tambm oferecem outro servio tal que, dado um
CEP, retorna os tipos de frete e seus valores. Esses servios isoladamente resolvem
determinados problemas especficos. Quando compostos, esses resolvem outros
tipos de problemas. Simples de entender?
Ao estabelecer em uma empresa uma lgica representada por um inventrio de

servios altamente reusveis, fornecemos eio ara que uma grande extenso
dos turos equisitos a automao e negcios seja umprida por eio da
composio de servios. Esse princpio trata de servios se juntarem e serem
acessados de forma a englobar e atender um problema maior.
Estas ca actersticas se relacionam e uma forma interdependente. Podemos

deduzir que o Baixo Acoplamento reduz a Alocao de Recursos; Contrato
Padronizado forma as bases para o Descobrimento; Alocao de Recursos reduzida

maximiza de Reutilizao; Descobrimento promove Reutilizao; Autonomia reduz a

Alocao de Recursos; Baixo Acoplamento permite Autonomia.

plataforma central e gerenciamento e atividades que fornecem enefcios mo

transformao de dados e gerenciamento e transaes.
Em outras palavras, a orquestrao

representa um processo de negcio
executvel centralizado e nico, chamado
coordenador, responsvel por controlar e
coordenar as interaes entre diferentes
servios. Ele o c ra que vai nvocar
combinar os servios solados servios
compostos. Em uma analogia simplista, a
orquestra seria um servio composto, os
msicos seriam servios individuais e o
maestro seria coordenador. Ele diz quando
um para e quando o outro comea ele
a figura central ue coordena a interao
entre todos os msicos/servios.
A orquestrao inclui o gerenciamento de transaes entre servios individuais e

emprega uma abordagem centralizada para a composio do servio, como
apresentado na imagem abaixo. Alm disso, lgica de processo e negcio, a
orquestrao, ertence organizao, .e., ma lgica privada e ntra-organizao
contraste com a coreografia.
No contexto de web services, existe uma linguagem para facilitar a orquestrao das
chamadas de servios: Web Services Business Process Execution Language (WS-
BPEL)! Essa uma linguagem tvel, m ariveis, tratamento e exceo,

que segue o adro OASIS utilizada para especificar es de processos de

negcios orquestrar servios em um fluxo de processos.
Coreografia: em contraste com a orquestrao, no h um coordenador central. Em

vez disso, cada servio envolvido na coreografia sabe exatamente quando executar
suas operaes e com quem interagir. A oreografia um s ro colaborativo
distribudo descentralizado om oco a troca de mensagens rocessos e
negcio blicos. Pois , aqui o processo negcio pblico e inter-organizaes.
Todos os participantes da coreografia precisam estar cientes do processo de

negcio, das operaes a serem executadas, das mensagens a serem trocadas, e
do momento da troca de mensagens. A orquestrao organizada por
coordenador, fazendo verificaes de pr-condies e ps-condies. J na
coreografia, todos auxiliam no fluxo das operaes.
A coreografia descreve as nteraes entre servios, o asso ue a orquestrao

representa o controle do onto e vista de uma das partes. Isto significa que uma
coreografia difere de uma orquestrao em relao ao local onde a lgica que
controla as interaes entre os servios envolvidos devem residir. H um grande
esforo na ordenao de mensagens e na interao entre os participantes.
No contexto de web services, existe uma linguagem para facilitar a coreografia das
chamadas de servios: Web Services Choreography Description Language (WS-
CDL)! Essa uma linguagem descritiva que descreve colaboraes ponto-a-ponto
de participantes ao definir, partir de um onto e vista global, m mportamento
observvel comum e complementar.

Por fim, vamos falar um pouco sobre Service Component Architecture (SCA). Trata-
se de uma tentativa iniciada por fornecedores de software (Ex: BEA, IBM, Oracle,
SAP, etc) de simplificar a construo de uma Arquitetura Orientada a Servios. Alis,
trata-se de um odelo e programao imples, orm oderoso, ara construir
aplicativos com base em OA.
Ele baseado na ideia de que funes do negcio so providas como uma srie de
servios, os quais so combinados a fim de criar solues que sirvam a uma
necessidade particular. Estas aplicaes podem conter tanto servios novos criados
especificamente para a aplicao, as ambm nes do egcio rovenientes
de sistemas e aplicaes, as quais so eutilizadas como arte da composio.
SCA prov um odelo para composio e servios para criao e componentes

de servios, ncluindo euso e funes de aplicaes existentes dentro a
composio SCA. Ele um modelo que tem o objetivo de incluir uma grande
variedade de tecnologias para componentes de servios e para os mtodos de
acesso que so utilizados para conect-los.
Para componentes, sto nclui o enas iferentes linguagens e programao,

mas ambm ameworks, ambientes geralmente utilizados m as inguagens.
Para mtodos de acesso, composies SCA permitem o uso de vrias tecnologias
de comunicao e acesso a servios que so usadas em geral, incluindo, por
exemplo, Web Services, sistemas de mensagens e Remote Procedure Call (RPC).
O CA foca em rs aspectos: Composio (como empacotar componentes de

software para eles serem reutilizados por outras aplicaes); Montagem (define
como componentes podem ser colocados juntos e trat-los como um nico servio;
e Poltica (como tratar restrio de acesso ou assinatura digital em uma arquitetura
orientada a servios).

Ademais, importante que disponibilizar m ecanismo iciente para a busca de

servios, a forma de um egistro e servios dinmico. Se parceiros, clientes e
consumidores tiverem um repositrio nico para acessar detalhes de um servio
como contratos, polticas, modelos de dados, especificaes, componentes, etc a
mudana e o versionamento tendem a se tornar mais controlados.
Da mesma forma, importante que toda organizao que detenha um portflio

considervel de servios disponibilize um mecanismo eficiente de consulta, tambm
em nvel organizacional. Desta forma, oda vez que consumidores estiverem
interessados guns servios, seu ecanismo e registro poder ajud-los
obter respostas mais facilmente.
Quando mudanas so eminentes, ter um mecanismo que possibilite a acomodao

de mudanas apenas com esforo de configurao e com menos implementao
muito importante. Para o OA, o mportantes ue questes de protocolos, Is,
linguagens, c nectores e plataformas no ejam roblemas grandes para quando
voc quer mudar o comportamento ou nterface de um servio.
necessrio ue voc ossua uma infraestrutura de integrao que acomode

questes de mudanas e forma simples e rpida. Neste caso, o uso de um bom
barramento de servios (Enterprise Service Bus) primordial para lidar com questes
de versionamento de servios. Atravs de tcnicas de roteamento, transformao e
mediao de mensagens, simples acomodar vrias verses de um servio.
Mais nda, m SB ode complementar ividades de um sistema de registros.

Em resumo, as estratgias usuais sobre como lidar com versionamento de servios
so: (1) revisar com cuidado aspectos de desenho de servios; (2) usar repositrios
de gerenciamento de artefatos dos servios; e (3) usar um sistema de registro
eficiente para revelar servios.

Gabarito: C
14. (CESPE 013 ERPRO alista de Sistemas) Por ser dependente de

tecnologia, o ambiente de SOA tem de ser implementado em protocolos
especficos.
Comentrios:
Galera, s imos nsistentemente arquitetura orientada a servios

independente d implementao ecnologia. Em outras palavras, h diversas
modelos arquitetnicos de implementao de uma arquitetura orientada a servios.
Veremos agora algumas formas de implementar essa arquitetura em uma
organizao. Vamos comear pelo modelo mais primitivo...
Conforme vimos em aula, a arquitetura independente de tecnologia.
Gabarito: E
15. (CESPE 013 ERPRO alista de Sistemas) No nvel do aplicativo, os

servios fornecidos pela SOA existem como softwares fisicamente dependentes
que do suporte obteno dos objetivos estratgicos associados a computao
orientada a servios.
Comentrios:
Quando falamos em servios fracamente acoplados, estamos rendo zer os

servios o ndependentes s utros, .e., e uver a mudana na
implementao ervio, m nada afetar o estante. Vocs vero esse conceito
de fraco acoplamento dezenas, talvez centenas, de vezes em concursos sugiro
memoriz-lo! Abaixo segue uma lista de definies de SOA que eu j encontrei...
Conforme vimos em aula, os servios so independentes.
Gabarito: E
16. (CESPE 013 ERPRO A alista de Sistemas) Em um ambiente de SOA,

recursos em uma rede so disponibilizados como servios dependentes entre si,
que s podem ser acessados com o conhecimento de sua implementao
interna.

Comentrios:
to mportante visualizar e osicionar Arquitetura Orientada a Servios como

um modelo quitetura que stico qualquer lataforma de ecnologia. Ao
fazer isso, uma empresa tem a liberdade para perseguir continuamente os objetivos
estratgicos associados computao orientada a servios, aproveitando os avanos
tecnolgicos futuros.
(a) Errado. Nem todos os aplicativos devem ser implementados como um servio.
Ademais, devem permitir a integrao de componentes de quaisquer plataformas
servios so independentes de tecnologia.
(b) Correto. No tem muito a acrescentar nesse item observem que ele apenas
cita HTTP (ele no restringe a esse protocolo).
Alm da boa dosagem de ise senho m servios, mportante voc race

claramente conjunto olticas relacionadas gesto dos ervios. Boas prticas
neste aspecto envolvem ter um repositrio nico na organizao para manter
questes de dependncia e rastreabilidade entre artefatos de um servio numa forma
controlada, alm de definir o tempo de guarda das verses.
(c) Correto. Uma boa prtica definir o tempo de guarda das verses de um servio
em funcionamento.
O que o versionamento de servios? Quando e est inserido num programa SOA,

vrios ojetos e oftware o riados ealizados em paralelo. medida que os
projetos amadurecem, vrios servios so disponibilizados para uso pelas aplicaes,
seja para satisfazer algum critrio da soluo que est sendo criada, seja para
disponibilizar tal servio a um parceiro ou cliente.
(d) Correto. Como so projetos criados e realizados em paralelo e que evoluem

como servios, existem tambm verses (incluindo operaes e implementaes).
O que autonomia? a capacidade de um servio se auto-administrar. Um servio

autnomo aquele que independe de um elemento externo para executar sua lgica!
Einh? Como , professor? Vamos nsar, r xemplo, ente xecuo
servio! A autonomia de servios um princpio que visa fornecer servios com
independncia de seu ambiente de execuo.

c) I e IV.
d) V.
e) II e V.
Comentrios:
(I) Correto, pode-se considerar como uma coleo de servios; (II) Errado, no utiliza
tecnologias de bancos de dados para troca de mensagens a questo viajou; (III)
Errado, garante servios fracamente acoplados e altamente coesos; (IV) Correto,
realmente uma funo do sistema disponibilizada como um servio; (V) Errado, deve
funcionar de forma independente (fracamente acoplada) do estado de outros
servios. Portanto, os itens corretos so I e IV.
Gabarito: C
10. (FCC 013 AL/RN - A alista de istemas) Uma Arquitetura Orientada a

Servios (SOA) uma forma de arquitetura de sistemas distribudos que
tipicamente caraterizada pelo seguinte:
I. Viso lgica: O servio uma viso abstrata e lgica de programas, bancos de

dados, processos de negcio etc. definida em termos de o que isso faz,
carregando em conjunto uma operao de nvel de negcio.
II. Orientao de mensagens: O servio formalmente definido em termos de

mensagens trocadas entre agentes prove- dores e requisitantes.
III. Orientada descrio: Um servio descrito por um metadado que pode ser
processado por uma mquina. Essa descrio expe apenas detalhes que so
importantes para o servio.
IV. Granularidade: Servios tendem a ser um pequeno nmero de operaes

com mensagens relativamente grandes e complexas.
Est correto que exposto em:
a) I, II, III e IV.

b) III e IV apenas.
c) II e III, apenas.
d) I e II, apenas.
e) I, III e IV, apenas.

Comentrios:
(I) Correto, o servio definido em termos funcionais, tipicamente implementando

operaes de negcios. A viso lgica do servio o abstrai dos programas, bases de
dados, processos de negcios, etc, necessrios sua implementao; (II) Correto, o
servio formalmente definido em termos de mensagens trocadas entre unidades
de software provedoras e consumidoras do servio. A estrutura interna das unidades
de software, incluindo sua linguagem de programao, sua estrutura de dados, etc.
so deliberadamente abstradas na SOA. Este baixo acoplamento entre aplicaes
provedoras e consumidoras de um servio traz benefcios significativos para
sistemas legados: a transparncia da implementao interna das aplicaes de uma
arquitetura SOA permite que qualquer componente de software ou aplicao seja
envolvido por uma interface de mensagens e adaptado a uma definio de servios
formal; (III) Correto, um servio descrito por uma metalinguagem processvel por
mquinas. A descrio suporta a natureza pblica da SOA: apenas os detalhes do
servio relevantes a seu uso so includos na descrio; (IV) Correto, servios tendem
a utilizar um pequeno nmero de operaes com mensagens relativamente grandes
e complexas;
Gabarito: A
11. (FCC 013 /SP alista e Sistemas) A Arquitetura Orientada a Servios

(SOA) possui um modelo de referncia que descreve diversas propriedades
importantes do SOA. Uma dessas propriedades refere-se ao fato de que a
descrio de um servio deve fornecer dados suficientes para permitir que um
consumidor e um provedor de servios possam interagir entre si. A propriedade
descrita recebe a denominao de:
a) funcionalidade do servio.
b) acessibilidade do servio.
c) poltica do servio.
d) semntica do servio.
e) conformidade do servio.
Comentrios:
A descrio de um servio possui cinco propriedades: acessibilidade dos servios;

funcionalidades do servio; polticas relacionadas com um servio; interface do
servio; e limites da descrio. A acessibilidade inerente ao relacionamento de

SOAP que podem ser encontrados no caminho de uma mensagem de um

remetente para um receptor final. Bacana?
Os blocos de cabealhos SOAP podem ser processados por ns intermedirios

SOAP e pelo n receptor SOAP final. No tanto, m licativo eal, nem sempre
cada n processa cada bloco de cabealhos. Cada n geralmente projetado para
processar determinados blocos de cabealhos e cada bloco de cabealhos
processado por ns especficos.
Ns o dissemos nda se SOAP um protocolo tateful ou tateless, as antes

de descobrir, emos que saber ue so es conceitos. Stateful significa que o
servidor armazena informaes sobre o cliente e as utiliza em diversas requisies.
Stateless justamente o contrrio, i.e., o estado do servio no persistido entre
requisies subsequentes. O HTTP e o SOAP, por default, so protocolos stateless.
O SOAP, definido pela W3C, consiste basicamente dos elementos descritos abaixo:
Envelope Envolope):
Trata-se do mento-raiz do ocumento XML dentifica o ocumento XML como

uma ensagem OAP. Ele funciona como um recipiente que contm os demais

elementos da mensagem (Ex: Header, Body, etc). Ele possui dois atributos: namespace,
que define o Envelope como um Envelope SOAP; e encodingStyle, que define os tipos
de dados utilizados em um documento. obrigatrio!
Cabealho (Header):
Ele carrega informaes adicionais ecficas para a aplicao, mo A tenticao,

Autorizao, Pagamento, tc. Ele pode, por exemplo, especificar assinatura digital
para servios protegidos por senha. Podem ser definidos vrios cabealhos. Ele
opcional, mas caso seja utilizado deve ser o primeiro elemento do Envelope. Ele
tem trs atributos: mustUnderstand, actor e encodingStyle.
Corpo Body):
Ele contm o payload, i.e., a mensagem SOAP. Trata-se de um elemento obrigatrio

que capaz de empacotar chamadas RPC, reportar erros, enviar operaes UDDI,
entre outros. O elemento Body pode conter um elemento opcional Fault, sado
para carregar ensagens de status mensagens e erros etornadas elos s
processarem a ensagem. obrigatrio!

As Pginas Brancas contm informaes gerais sobre a organizao que est

oferecendo o servio, tais como: nome do negcio e descrio do negcio (de
preferncia, em diversas lnguas). Utilizando ssas nformaes possvel encontrar
algum ervio obre o ual se pode conhecer algumas informaes. H tambm
informaes de contato do negcio (Ex: Endereo, Telefone, Fax, Identificadores).
As Pginas A arelas ntm ma classificao do ervio u egcio isponveis

baseado axonomias adronizadas (Ex: IC, CS, UNSPSC). Como cada
organizao pode fornecer uma srie de servios, pode haver vrias pginas
amarelas (cada uma descrevendo um servio) associadas a uma pgina branca
(dando informaes gerais sobre o negcio).
As Pginas Amarelas usam os esquemas de categorizao industrial mais aceitos no

mercado, cdigos de indstria, cdigos de produtos, cdigos de identificao
comerciais e similares para tornar mais fcil para as empresas procurarem por meio
de listas e encontrarem exatamente o que elas desejam. As ginas marelas
fornecem mais detalhes sobre a empresa.
As Pginas erdes ontm nformaes tcnicas obre como c ssar m

Service. Elas so utilizadas para indicar os servios oferecidos por cada negcio,
incluindo todas as informaes tcnicas envolvidas na interao com o servio. Em
geral, essas informaes incluem um ponteiro para uma especificao externa e um
endereo para invocar o servio.

estrutura hierrquica formada por: ntidade e gcio Business ntity), ervio

Negcio (Business Service), Template de Ligao (Binding Template) e tModel.
Conforme vimos em aula, basta lembrar da sigla! UDDI Universal Description,

Discovery and Integration (Integrao, Descoberta e Descrio Universal). Dessa
forma, trata-se realmente de uma especificao tcnica que tem como objetivo
descrever, descobrir e integrar Web Services. baseada em XML? Sim! Permite
descrever relaes hierrquicas? Sim!
Gabarito: C
12. (CESPE 008 TJ A alista Judicirio ecnologia da Informao) O servio

UDDI fornece uma interface para publicar e atualizar informaes acerca de
servios web; possibilita pesquisar descries WSDL pelo nome; prov uma
interface que possibilita executar consultas de modo a recuperar uma entidade
que corresponda a uma chave ou recuperar entidades que correspondam a um
conjunto de critrios de busca.
Comentrios:
A specificao D fornece d nterfaces mportantes: ublisher terface

Inquiry rface. A primeira interface define dezesseis operaes para que um
provedor de servios possa gerenciar e publicar informaes sobre um determinado
servio web. J a segunda interface define dez operaes de busca de registro e
informaes especficas de registros.
Conforme vimos em aula, a questo trata das interfaces: Publisher e Inquiry.
Gabarito: C
13. (CESPE 008 TJ - A alista Judicirio ecnologia da Informao) O WSDL

separa a parte abstrata de uma descrio de servio da parte concreta; nessa
descrio, a parte concreta contm as definies de tipos usados pelo servio e
a parte abstrata especifica como e onde o servio pode ser contatado. Os
documentos WSDL podem ser acessados via um servio de diretrio como o
UDDI; as definies WSDL podem ser geradas a partir de definies de interfaces
escritas em outras linguagens.
Comentrios:

O WSDL epara a descrio ervio m erspectivas: bstrata ncreta!

A perspectiva abstrata trata da interface do servio. Em outras palavras, ela descreve
o que o servio faz seus tipos, suas operaes, suas entradas, suas sadas, suas
mensagens fault, entre outros , porm sem dizer como o servio faz o seu trabalho
nem mesmo como acessar esse servio.
A perspectiva concreta trata da implementao do servio. Em outras avras, la

descreve como ealizar o ervio rotocolos comunicao, odificao s,
localizao, rtas, ndereo ede, tc. A perspectiva concreta contm a
perspectiva abstrata e adiciona informaes sobre como o servio se comunicar e
quem pode alcan-lo. Professor, qual a vantagem de haver essa separao?
Elas fazem isso ao eliminar a necessidade de envolvimento dos usurios com os

detalhes complexos e com a estrutura do WSDL. As definies WSDL tambm podem
ser geradas a partir de definies de interface escritas em outras linguagens, como
JAX-RPC. Ele no define caractersticas no-funcionais do servio (Ex: tempo de
resposta, escalabilidade, segurana). Ademais, efine quatro tipos de operaes:
Conforme vimos em aula, a questo inverteu as bolas! As definies de tipo

pertencem parte abstrata; e como/onde o servio pode ser contatado (endereo
de rede, portas, etc) pertence parte concreta. Alguns me perguntam se as
definies WSDL podem ser geradas a partir de definies de interfaces escritas em
outras linguagens. Sim, em teoria, elas podem ser escritas em outras linguagens
que, no, XML.
Gabarito: E
14. (CESPE 008 TJ - alista Judicirio ecnologia da Informao) O SOAP

encapsula mensagens que podem ser transmitidas via HTTP; permite o modelo
de interao cliente-servidor; define como usar XML para representar
mensagens de requisio e resposta. Um documento XML transportado no
corpo de uma mensagem SOAP; no modelo cliente-servidor, o corpo de uma
mensagem SOAP pode conter uma requisio, mas no uma resposta.
Comentrios:
SOAP encapsula mensagens que podem ser transmitidas via HTTP? Sim, assim como
outros protocolos de comunicao. Permite o modelo de interao cliente-servidor?
Define como usar XML para representar mensagens de requisio e resposta? Sim,
utiliza um paradigma de requisio/resposta, tpico de aplicaces cliente-servidor.

LISTA DE EXERCCIOS COMENTADOS (CESPE)

I. Viso lgica: O servio uma viso abstrata e lgica de programas, bancos de

dados, processos de negcio etc. definida em termos de o que isso faz,
carregando em conjunto uma operao de nvel de negcio.
II. Orientao de mensagens: O servio formalmente definido em termos de

mensagens trocadas entre agentes prove- dores e requisitantes.
III. Orientada descrio: Um servio descrito por um metadado que pode ser
processado por uma mquina. Essa descrio expe apenas detalhes que so
importantes para o servio.
IV. Granularidade: Servios tendem a ser um pequeno nmero de operaes

com mensagens relativamente grandes e complexas.
Est correto que exposto em:
a) I, II, III e IV.

b) III e IV apenas.
c) II e III, apenas.
d) I e II, apenas.
e) I, III e IV, apenas.
11. (FCC 013 P /SP alista e Sistemas) A Arquitetura Orientada a Servios

(SOA) possui um modelo de referncia que descreve diversas propriedades
importantes do SOA. Uma dessas propriedades refere-se ao fato de que a
descrio de um servio deve fornecer dados suficientes para permitir que um
consumidor e um provedor de servios possam interagir entre si. A propriedade
descrita recebe a denominao de:
a) funcionalidade do servio.
b) acessibilidade do servio.
c) poltica do servio.
d) semntica do servio.
e) conformidade do servio.
12. (FCC 013 RT/11 alista de Sistemas) Em relao aos aspectos do projeto
de servios em SOA, INCORRETO afirmar:
a) O meio de acesso ao servio estabelecido no Contrato de Servio.

b) Os servios tm controle sobre a lgica que os encapsulam.

21. (FCC 008 PE-RS cnico m formtica - rea Sistemas) A identificao

do documento XML, como uma mensagem SOAP, est contida no elemento da
estrutura SOAP denominado:
a) root.
b) body.
c) envelope.
d) fault.
e) header.

Aula 01 PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Aula 01 PDF

Uploaded by

Copyright:

Available Formats

Analista de Sistemas Terracap

Curso de Engenharia de Software

RQ TURA ORIENTADA A SERVIOS (SOA)

J um servio um mecanismo que permite acessar um conjunto de recursos, no

No necessidade de sses terceiros conhecerem o provedor de servios,

De acordo com Thomas Erl:

Dentro de uma soluo orientada a servios, as unidades de lgica (servios)

Galera, basta pensar em qualquer empresa de prestao de servio. Existe um

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pg. 3 de 162

muito importante visualizar e posicionar a Arquitetura Orientada a Servios como

No ercado ual, plataforma de tecnologia mais sociada com realizao e

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pg. 5 de 162

Imaginem gora que ns emos ue substituir ma aplicao mensa do anco

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pg. 7 de 162

servios, so consumidores de servio. A descrio permite que consumidores

O Modelo de Referncia do SOA, como suporte s dinmicas da interao com

A Descrio do ervio epresenta a informao ecessria para utilizar m servio.

Uma poltica representa alguma restrio ou condio sobre o uso, distribuio ou

O Contexto de Execuo de uma interao de servio o conjunto de elementos

Descrio do ervio um njunto e informaes necessrios para utilizar m

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pg. 10 de 162

Esse registro de servios geralmente contm m epositrio e servios sociado

O olicitante de servio, to, e conecta ao restador de servio, emotamente

Existem dois odelos bastante similares que implementam odelo riangular m

Esse ltimo modelo funciona assim: prestadores de servios publicam servios no

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pg. 14 de 162

Recentemente, algumas questes comearam a cobrar tambm a modelagem de

Normalmente, sa-se as bordagens op-down bottom-up o rocesso e

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pg. 16 de 162

Pessoal, esse um princpio muito tranquilo! e se esperar que um ervio seja

Um ervio eutilizvel aquele que no a rega particularidades cnicas de uma

Estrategicamente, ele capaz promover um maior retorno sobre o investimento ao

Autonomia e Servios Service Autonomy):

O que autonomia? a capacidade de um servio se auto-administrar. Um servio

E qual a consequncia disso? Maior confiabilidade, na medida em que os servios

O o e se autogovernar ou onomia e servio ode trazer guns enefcios

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pg. 20 de 162

o mnimo de dependncias com outros servios e as execues das funcionalidades

Essa autonomia edida e disponibilizada nos ontratos rmais, endo mo

Independncia de Estados e Servios (Service Statelessness)

Servios so xplicitamente projetados ara minimizar o erodo urante o ual e

Os ervios evem itar alocao de recursos or uito empo! omenda-se

Visibilidade de Servios Service Discoverability):

O termo em ingls discoverability! Como esse vocbulo no existe, traduziram

O objetivo principal fazer m que o servio e torne visvel a todos, entando

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pg. 21 de 162

so projetados para que sejam encontrados e seus propsitos e capacidades sejam

A aplicao desse princpio aps a implantao de um servio pode comprometer

Composio de Servios (Service Composability):

Servios o projetados ara que atuem mo articipantes e icazes de uma

Talvez voc e lembre que um os bjetivos ue selecionamos ara o princpio a

Vamos ver um exemplo? Os rreios isponibilizam m servio al ue, dado m

Ao estabelecer em uma empresa uma lgica representada por um inventrio de

Estas ca actersticas se relacionam e uma forma interdependente. Podemos

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pg. 22 de 162

maximiza de Reutilizao; Descobrimento promove Reutilizao; Autonomia reduz a

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pg. 23 de 162

plataforma central e gerenciamento e atividades que fornecem enefcios mo

Em outras palavras, a orquestrao

A orquestrao inclui o gerenciamento de transaes entre servios individuais e

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pg. 25 de 162

que segue o adro OASIS utilizada para especificar es de processos de

Coreografia: em contraste com a orquestrao, no h um coordenador central. Em