Arquitetura Orientada a Serviços

Prévia do material em texto

ARQUITETURA DA INFORMAÇÃO 1 
 ....................................... 2 Aula 7: Arq. Orientadas a Serviços - Conceitos e Definições
 ............................................................................................................................. 2 Introdução
 ................................................................................................................................ 3 Conteúdo
Princípios do SOA .............................................................................................................. 3 
Conceitos de arquitetura orientada a serviço .............................................................. 5 
Governança e Segurança ................................................................................................. 6 
Telas sobre governança ................................................................................................... 7 
Aspectos de segurança ..................................................................................................... 8 
Integração e uso de tecnologias legadas .................................................................... 10 
Uso de SOA ....................................................................................................................... 11 
Uso de Web Services ........................................................................................................ 14 
Atividade proposta .......................................................................................................... 16 
........................................................................................................................... 16 Referências
 ......................................................................................................... 17 Exercícios de fixação
Chaves de resposta ..................................................................................................................... 21 
 
 
 ARQUITETURA DA INFORMAÇÃO 2 
Introdução 
Como solução para a gestão de ambientes heterogêneos e reuso de 
componentes já existentes, surge uma nova filosofia em termos arquiteturais 
para a criação de sistemas corporativos. 
 
As arquiteturas orientadas a serviços tratam as diferentes tecnologias 
envolvidas, sejam elas novas ou antigas, a exemplo dos mainframes, como 
simples componentes que deverão expor ou consumir serviços, sempre 
intermediados pelo ferramental provido na arquitetura. 
 
Objetivo: 
1. Compreender os princípios fundamentais de uma arquitetura orientada a 
serviços; 
2. Analisar as possibilidades de integração entre plataformas e uso de 
tecnologias legadas. 
 
 
 
 
 
 
 
 
 
 ARQUITETURA DA INFORMAÇÃO 3 
Conteúdo 
 
Princípios do SOA 
O que é? 
As arquiteturas orientadas a serviços (SOA, do inglês Service Oriented 
Architecture) são a evolução natural da concepção de sistemas, visando o reuso 
e a interoperabilidade. 
 
Como funciona? 
Um serviço é definido como uma função independente, sem estado (stateless), 
que aceita uma ou mais requisições e devolve uma ou mais respostas por meio 
de uma interface padronizada e bem-definida. 
 
E também 
Serviços podem também realizar partes discretas de um processo, tal como 
editar ou processar uma transação, e não devem depender do estado de outras 
funções ou processos. 
 
A tecnologia utilizada para prover o serviço, tal como uma linguagem de 
programação não pode fazer parte da definição do mesmo. 
 
Incialmente os sistemas eram monolíticos, passando a trabalhar com 
metodologias estruturadas ou orientadas a objetos. Com o uso de redes, 
passamos a ter sistemas cliente-servidor, os quais evoluíram para sistemas 
divididos em camadas, como na arquitetura MVC (Model, View e Control). Com 
as necessidades transacionais e de distribuição de processamento, torna-se 
comum o uso de objetos distribuídos e posteriormente sistemas baseados em 
componentes corporativos. Finalmente surgem os serviços orientados a 
componentes, definindo a base do SOA. 
 
Uma arquitetura baseada em componentes considera a divisão das 
funcionalidades do todo em funções menores, encapsuladas em componentes, 
 
 ARQUITETURA DA INFORMAÇÃO 4 
os quais podem estar em diferentes locais físicos, quando tratamos de objetos 
distribuídos. 
 
A grande vantagem dos componentes é o fácil reuso e sua substituição, o que 
simplifica a manutenção, caracterizando os requisitos de negócio principais no 
uso de SOA. 
 
Embora os Web Services sejam muitas vezes confundidos com o SOA em si, 
este é apenas o meio de interfaceamento de serviços mais comumente adotado 
nessa arquitetura. Outros elementos, como o ESB (Enterprise Service Bus) e 
ferramentas de orquestração de serviços devem estar presentes para viabilizar 
esse tipo de arquitetura. 
 
Um termo muito utilizado em termos de programação é "acoplamento ", que 
trata do nível de interdependência entre os módulos de um sistema. Uma das 
características do SOA é justamente o baixo acoplamento, e o módulo é 
considerado coeso quando possui uma atividade bem-definida e um baixo 
acoplamento. 
 
Um ambiente SOA deve ser independente de plataforma, conferindo a 
característica de neutralidade, e precisa ser baseado em padrões e apresentar 
contratos de uso formais entre os pontos de uso, o que determina obrigações 
específicas entre produtor e consumidor. 
 
Também deve ocorrer um grande nível de abstração do serviço frente a sua 
implementação, e apresentar meios de publicação popularizados, apresentando 
sempre a especificação das funcionalidades da interface do serviço, sem 
demonstrar sua implementação. Da mesma forma, um serviço deve ser 
consumível de forma prática, com ferramentas para descoberta e uso 
automatizado. 
 
 
 ARQUITETURA DA INFORMAÇÃO 5 
Qualquer funcionalidade do ambiente deve ser relevante, apresentando funções 
em uma granularidade reconhecida como significativa, bem como deve garantir 
o reuso do serviço sem a necessidade de cópia ou adaptações. 
 
Pode-se considerar o SOA como um paradigma arquitetural no qual 
componentes de aplicações são distribuídos, combinados e consumidos através 
de interfaces de serviços. Logo, não trata de uma tecnologia específica, e sim 
de uma metodologia de projeto e organização da infraestrutura de 
funcionalidades em um ambiente corporativo. 
 
Conceitos de arquitetura orientada a serviço 
Alguns conceitos devem ser necessariamente implementados para viabilizar 
uma arquitetura orientada a serviços: 
 
Serviços 
Trata de funções disponibilizadas por um sistema computacional para outros 
sistemas. Deve funcionar de forma independente de outros serviços e possuir 
interface bem-definida, como no caso dos Web Services. 
 
Descritores 
Refere-se ao conjunto de parâmetros, regras e políticas envolvidas na chamada 
do serviço, tendo como exemplo o WSDL. 
 
Publicação e Descoberta 
A publicação de um serviço trata de sua divulgação, enquanto a descoberta 
ocorre quando um futuro consumidor desse serviço obtém informações acerca 
da existência do mesmo. Podem ser utilizados repositórios de registros ou 
serviços de nomes e diretórios. 
 
Exemplos de repositórios são o OASIS ebXML e UDDI, tratando de ferramentais 
onde podem ser armazenados e gerenciados artefatos como XML Schemas e 
WSDL. 
 
 ARQUITETURA DA INFORMAÇÃO 6 
Um serviço de nomes e diretórios provê informações acerca das ligações com 
determinados componentes. Nele são encontradas informações acerca da 
localização de descritores e objetos, como no caso do JNDI. 
 
Modelo de Dados 
Trata da especificação de um modelo de dados associado, comoW3Cs WSDL, 
trazendo um vocabulário comum ao ambiente, o que permite a serialização de 
parâmetros em plataformas distintas, garantindo a interoperabilidade. 
 
Contratos de Serviço 
Os serviços devem ser utilizados segundo contratos bem-definidos, os quais 
devem ser aceitos pelo seu consumidor. 
 
 
 
O que podemos observar é que a arquitetura orientada a serviços nada mais é 
que a evolução natural da arquitetura de sistemas tradicional para solucionar as 
necessidades de desenvolvimento e capacidade de adaptação às novas 
demandas, dentro de um mercado cada vez mais exigente em termos de 
qualidade e agilidade. 
 
Governança e Segurança 
Outra característica desejável em arquiteturas desse tipo é a possibilidade de 
governança. Esse termo refere-se à gestão de políticas e processos necessários 
à boa utilização da arquitetura, com a definição de papéis e determinação de 
objetivos claros. 
 
 
 ARQUITETURA DA INFORMAÇÃO 7 
Com relação aos papéis, estes se referem às diversas pessoas envolvidas com o 
sistema, particularmente aquelas que assumem tarefas da gestão de tecnologia 
da informação e projetos. 
 
As políticas definem regras claras, que deverão ser seguidas por pessoas com 
diferentes papéis, para que os objetivos primordiais do uso da arquitetura 
sejam alcançados. 
 
 Os processos definidos para garantir a governança do SOA envolvem: 
 Definição de políticas de uso da arquitetura; 
 Estabelecimento de metodologias de comunicação; 
 Estratégias de treinamento adequadas; 
 Implantação e acompanhamento de serviços. 
 
Muitas empresas definem os serviços de forma avulsa, integrando-os sem 
trabalhar com princípios de governança, o que pode se tornar bastante 
complicado à medida que os projetos surgem e a necessidade de controle fica 
mais clara. 
 
Uma boa solução de governança deve compreender o gerenciamento de todo o 
ciclo de vida dos diversos ativos, sejam estes serviços, modelos, servidores, ou 
outros, e deverá, portanto, englobar todos os passos da criação até a remoção 
de um serviço, incluindo análise, modelagem, codificação, testes e implantação. 
 
Telas sobre governança 
As figuras seguintes mostram duas telas voltadas para governança oferecidas 
por uma das ferramentas Oracle voltadas para o tema: Oracle Enterprise 
Manager SOA Management Pack Enterprise Edition. 
 
É possível observar, na primeira, o acesso a dados históricos em um painel de 
instrumentos com análises estatísticas, enquanto a segunda demonstra a 
gestão de transações de negócios através da ferramenta. 
 
 ARQUITETURA DA INFORMAÇÃO 8 
 
 
 
 
 
Aspectos de segurança 
Finalmente, os aspectos de segurança não podem ser deixados de lado em uma 
arquitetura orientada a serviços, e não basta pensar apenas em padrões de 
segurança para Web Services, como WS-Trust, WS-Security e SAML, mas sim 
 
 ARQUITETURA DA INFORMAÇÃO 9 
tratar de políticas de segurança que envolvam todos os componentes da 
arquitetura. 
 
Entre os elementos de segurança, podemos citar a autenticação e autorização, 
referentes à identificação de um elemento (usuário, processo, componente, 
entre outros) e a permissão do acesso a recursos por parte do mesmo. 
 
Quanto às informações, é comum o uso de assinatura digital para garantir a 
autenticidade e a confidencialidade. Essas informações devem ser protegidas no 
trânsito (transporte) entre o serviço e seu consumidor, sendo comum o uso de 
protocolos como SSL (Secure Socket Layer) e TLS (Transport Layer Security). 
 
É necessária uma gestão da base de dados de usuários, bem como 
implementação de Políticas de Segurança, as quais denotam um conjunto de 
regras de negócio que estabelecem o comportamento de um sistema de 
computação, podendo envolver os mais diversos participantes. 
 
Outro elemento importante é a rastreabilidade, ou seja, a possibilidade de 
efetuar o acompanhamento dos eventos históricos de determinado usuário, de 
modo a apurar a responsabilidade sobre qualquer tipo de ação na utilização da 
arquitetura. 
 
Todo esse conjunto de aspectos de segurança acabam levando à necessidade 
de sistemas gestores bastante complexos. Como exemplo, a figura seguinte 
mostra a gestão de segurança do Oracle Fusion Middleware, o qual utiliza 
muitas ferramentas do Java como o Java Key Store e o JAAS (Java 
Authentication and Authorization Service). 
 
 
 ARQUITETURA DA INFORMAÇÃO 10 
 
 
Integração e uso de tecnologias legadas 
Sistema legado é o termo utilizado em referência aos sistemas computacionais 
de uma organização que, apesar de serem bastante antigos, fornecem serviços 
essenciais, sendo comum a utilização de bancos de dados obsoletos. 
Normalmente, são aplicações complexas, de difícil manutenção, e que pelo grau 
de criticidade e custo para modernização continuam ativas. 
 
Devido à falta de documentação e saída dos desenvolvedores inicialmente 
envolvidos nos projetos, os sistemas legados podem apresentar problemas 
como: 
 
• Dificuldade para a compreensão das regras de negócio originalmente 
implementadas; 
• Desconhecimento dos requisitos que levaram a tomar determinadas decisões; 
• Incoerência na estruturação dos módulos de código; 
• Miscelânea de estilos de programação; 
 
 
 ARQUITETURA DA INFORMAÇÃO 11 
• Obsolescência das ferramentas de desenvolvimento e bases de dados; 
• Indisponibilidade de mão de obra qualificada; 
• Impossibilidade de reaproveitamento dos equipamentos nos quais são 
executados; para execução de softwares mais atuais. 
 
Todos esses fatores encarecem a manutenção, e como a substituição do 
sistema pode ser inviável, o comum é que as empresas procedam à 
modernização do sistema, segundo duas metodologias específicas: 
 
Modernização do tipo “caixa branca” 
Modernização do tipo “caixa branca”, a qual é iniciada com um processo de 
engenharia reversa, no qual componentes do sistema e seus relacionamentos 
são identificados, gerando uma abstração de alto nível. Este tipo de 
modernização acaba levando à necessidade de compreensão dos códigos do 
sistema e acaba incluindo alguma reestruturação do mesmo. 
 
Modernização do tipo “caixa preta” 
Modernização do tipo “caixa preta”, a qual envolve apenas a análise de 
entradas e saídas do sistema legado dentro de um contexto operacional, de 
forma a identificar as interfaces desse sistema. Esse tipo de modernização 
envolve apenas o empacotamento do sistema com uma camada de software 
que esconde a complexidade do sistema original, ao mesmo tempo em que 
fornece uma interface moderna de comunicação com os atuais padrões do 
mercado. 
 
Uso de SOA 
O uso de SOA estimula a reutilização dos aplicativos, os quais poderão durar 
décadas. Ou seja, os sistemas implementados hoje podem ultrapassar seus 
objetivos originais, sendo reutilizados na forma de componentes empresariais 
virtualizados, gerenciados como “caixas pretas” acessadas através de interfaces 
padronizadas. 
 
 
 ARQUITETURA DA INFORMAÇÃO 12 
Um exemplo de sistema crítico de difícil modificação são os que executam em 
mainframes na área bancária. Considerando o impacto monetário de apenas 
um dia parado, esses sistemas não permitem uma fácil substituição, e a criação 
de uma camada de chamadas via serviços, para acesso via novas tecnologias 
acaba sendo uma solução muito mais viável e menos arriscada. 
 
Com o uso de SOA é possível trabalhar em um mesmo ambiente, e de forma 
cooperativa, com o uso de componentes CORBA, JEE, Web Services SOAP ou 
REST, mensagerias, Sockets planos, entre muitos outros. 
 
A figura seguinte demonstra a diversidade de tiposde componentes que podem 
ser acessados em uma arquitetura orientada a serviços, ao ilustrar algumas das 
conexões disponibilizadas no Oracle SOA Suite. 
 
O que garante essa grande conectividade em um ambiente SOA é a presença 
do ESB (Enterprise Service Bus), apoiado por diversos tipos de Middleware. 
 
 
 ARQUITETURA DA INFORMAÇÃO 13 
 
 
Tendo o SOA como mediador e fornecedor de interface para o consumidor, 
garante-se o reuso de sistemas legados frente a novas tecnologias. 
 
Nessa arquitetura são aproveitados os diversos meios de interoperabilidade, 
trabalhando de forma conjunta, o que viabiliza a integração de aplicações 
distintas criadas em praticamente qualquer tecnologia recente ou legada. 
 
Em alguns momentos, mais de uma tecnologia pode ser utilizada para acessar 
determinada informação. Por exemplo, um mainframe poderia ser acessado via 
JEE, e as informações disponibilizadas dentro do SOA através de Web Services, 
o que permitiria a outras plataformas, como dotNet, gerar clientes (consumers) 
para os serviços providos pelo servidor. 
 
Em outras situações podem ser utilizadas mensagerias para a comunicação com 
outros sistemas, o que é muito comum na área financeira, o que permite 
 
 ARQUITETURA DA INFORMAÇÃO 14 
integrar o ambiente já existente de troca de mensagens com sistemas legados 
de armazenagem desses dados, como mainframes via JEE, ou disponibilizar 
para o público externo as informações pertinentes sem a perda da segurança 
no acesso aos dados tramitados no ambiente da mensageria. 
 
Esse tipo de ambiente, com uso de mensagerias na rede privada, está presente 
na comunicação entre instituições bancárias distintas, onde as solicitações de 
transferência de valores são mensagens em formato XML criptografado com 
chave 3DES, e assinado com chave privada RSA. 
 
Outro elemento de grande utilização dentro do ambiente SOA é a conexão com 
LDAP (Lightweight Directory Access Protocol), o que pode ser interessante para 
a gestão de certificados digitais e da segurança em conjunto com o JAAS (Java 
Authentication and Authorization Service). 
 
Como um protocolo de aplicação aberto, voltados para a gestão de informações 
hierarquicamente organizadas, o LDAP é um serviço de diretórios utilizado 
primordialmente para a gestão de informações pessoais em ambiente 
corporativo, sendo amplamente utilizado para a obtenção de um logon único 
dentro de todo o ambiente. 
 
Uso de Web Services 
Embora a arquitetura orientada a serviços seja um modelo conceitual, a 
abordagem de Web Services é a mais comum para sua implementação efetiva, 
o que pode ser observado em praticamente todas as ferramentas de mercado 
atuais como: Oracle SOA Suite, Microsofts SOA Platform e JBoss Enterprise SOA 
Platform. 
 
Através de Web Services é possível criar blocos funcionais de construção 
acessíveis através de protocolos de Internet padronizados de forma 
independente de plataformas e linguagens de programação. Esses serviços 
 
 ARQUITETURA DA INFORMAÇÃO 15 
podem representar tanto novas aplicações quanto apenas invólucros em torno 
dos sistemas legados existentes para disponibilizá-los no ambiente. 
 
Neste tipo de abordagem, dois elementos principais deverão ser considerados, 
os quais são o Service Provider (provedor do serviço) e o Consumer 
(consumidor). 
 
Service Provider - O provedor cria um Web Service e, eventualmente, publica 
sua interface e acesso à informação para o registro de serviços. Cada 
fornecedor deve decidir quais serviços irá expor, como balancear entre aspectos 
de segurança e facilidade de acesso. Também deve decidir em qual categoria 
os serviços devem ser listados em um dado Broker e que tipo de contrato será 
definido para a utilização do serviço. Ele registra os serviços e as listas de todos 
os perfis de acesso permitidos. Alguns Brokers são especializados em muitas 
listas, enquanto outros oferecem altos níveis de confiança nos serviços listados. 
Alguns cobrem um amplo panorama de serviços e outros têm foco dentro de 
uma indústria específica. O Universal Description Discovery and Integration 
(UDDI) define uma maneira de publicar e descobrir informações sobre os 
serviços da Web. Outros serviços incluem (por exemplo) ebXML (Electronic 
Business utilizando eXtensible Markup Language) e aqueles baseados na 
ISO/IEC 11179 Metadata Registry (MDR) padrão. 
 
Consumer - O consumidor de serviços, ou cliente do Web Service, localiza 
entradas no registro do Broker para encontrar as operações e, em seguida, liga-
se ao prestador do serviço para invocar um de seus Web Services. Seja qual for 
o serviço que os consumers precisam, eles têm que solicitá-lo ao Broker e, em 
seguida, conectar com o respectivo serviço e usá-lo. Consumers podem acessar 
vários serviços, se estiverem disponíveis. 
 
É interessante observar que um provedor pode ser consumidor de outro 
provedor, e que várias operações só poderão ser efetuadas quando combinados 
vários serviços através de orquestrações bem-definidas. 
 
 ARQUITETURA DA INFORMAÇÃO 16 
Quando esses agrupamentos ocorrem, para o usuário final fica disponível 
apenas o Web Service de solicitação primário, ou seja, a interface de serviços 
para comunicação com o usuário atua como fachada para todos os demais 
serviços envolvidos. 
 
Outra observação é a de que, mesmo que um Web Service possa ser 
disponibilizado diretamente, sem o uso do Broker, o ideal é que o faça através 
de outro Web Service disponibilizado pelo mesmo, de forma a não diminuir os 
aspectos de segurança e governança da arquitetura orientada a serviços. 
 
Atividade proposta 
Como atividade de fixação, instale o Oracle SOA Suite e faça uma análise das 
diversas opções de integração oferecidas por esta plataforma SOA. 
O download do produto está disponível no seguinte endereço: 
 
http://www.oracle.com/technetwork/middleware/soasuite/downloa
ds/index.html 
 
Referências 
Saudate, A. SOA aplicado: Integrando com web services e além. Editora Casa 
do Código, 2012. 
 
Hirama, K. Fugita, H. Soa - Modelagem, Análise e Design. Editora Campus, 
2012. 
 
Kaufman, M. Halper, F. Arquitetura Orientada a Serviços – SOA Para 
Leigos. Editora Alta Books, 2009. 
 
 
 
 
 
 ARQUITETURA DA INFORMAÇÃO 17 
Exercícios de fixação 
Questão 1 
Considerando-se a abordagem de Web Services para uma Arquitetura 
Orientada a Serviços, o que são o OASIS ebXML e UDDI? 
a) Protocolos de comunicação de Web Services. 
b) Descritores de Serviços. 
c) Repositórios de informações relacionados à publicação de descoberta. 
d) Gestores de segurança. 
e) Ferramentas de autenticação e autorização de usuários e componentes. 
 
Questão 2 
Em termos do SOA, analise as seguintes afirmativas: 
I - Um serviço é definido como uma função independente e sem estado 
(stateless). 
II – Os serviços devem se comunicar através de uma interface padronizada e 
bem definida. 
III - Um serviço deve ser consumível de forma prática, com ferramentas para 
descoberta e uso automatizado. 
IV – A única desvantagem deste tipo de ambiente é o grande aumento do 
acoplamento. 
Quantas afirmativas estão corretas? 
a) Todas estão corretas. 
b) Apenas uma está correta. 
c) Apenas duas estão corretas. 
d) Apenas três estão corretas. 
e) Nenhuma está correta. 
 
Questão 3 
Um ambiente SOA deve ser independente de plataforma, conferindo a 
característica de: 
a) baixo acoplamento 
b) neutralidade 
 
 ARQUITETURA DA INFORMAÇÃO 18 
c) coesão 
d) segurança 
e) governança 
 
Questão 4 
Qual dos elementos abaixo NÃO está relacionado aos aspectos desegurança 
em ambientes SOA? 
a) Confidencialidade 
b) Autenticação 
c) Interoperabilidade 
d) Autenticidade 
e) Autorização 
 
Questão 5 
Outra característica desejável em ambientes SOA é a possibilidade de gestão de 
políticas e processos necessários à boa utilização da arquitetura, com a 
definição de papéis e determinação de objetivos claros. A descrição se refere a 
qual característica específica? 
a) baixo acoplamento 
b) neutralidade 
c) coesão 
d) segurança 
e) governança 
 
Questão 6 
O que viabiliza a grande conectividade do SOA é a presença de um componente 
principal denominado: 
a) SOAP 
b) XML 
c) JDBC 
d) RMI 
e) ESB 
 
 ARQUITETURA DA INFORMAÇÃO 19 
Questão 7 
Existem diversos tipos de conectores disponíveis nas plataformas SOA. Entre as 
opções seguintes, qual delas NÃO é um conector que satisfaça à filosofia de 
utilização do SOA? 
a) SOAP 
b) REST 
c) CORBA 
d) Mensagerias 
e) JDBC 
 
Questão 8 
Existem várias técnicas que podem ser utilizadas para o reaproveitamento ou 
adaptação de sistemas legados. No caso de ambientes SOA, a técnica utilizada 
seria: 
a) Refatoramento 
b) Modernização do tipo "caixa preta" 
c) Modernização do tipo "caixa branca" 
d) Herança 
e) Substituição 
 
Questão 9 
Uma necessidade bastante comum em ambientes SOA é a gestão de 
segurança, e parte da solução envolve a utilização de certificados digitais, como 
os do tipo RSA. Qual conector do SOA estaria relacionado ao acesso a estes 
certificados em grande parte dos sistemas corporativos? 
a) CORBA 
b) RPC 
c) Mensagerias 
d) RMI 
e) LDAP 
 
 
 
 ARQUITETURA DA INFORMAÇÃO 20 
Questão 10 
Com relação à abordagem de Web Services para ambientes SOA, considere as 
seguintes afirmativas: 
I – Os dois principais papéis utilizados são Service Provider e Consumer. 
II – Um provedor não pode ser consumidor de outro provedor. 
III – Podem ser combinados vários serviços através de processos de 
orquestração. 
IV – Sempre que possível o Web Service deve ser acessado diretamente, sem a 
real necessidade de uso do broker. 
Quantas das afirmativas estão corretas? 
a) Todas estão corretas. 
b) Apenas uma está correta. 
c) Apenas duas estão corretas. 
d) Apenas três estão corretas. 
e) Nenhuma está correta. 
 
 
 
 ARQUITETURA DA INFORMAÇÃO 21 
Aula 7 
Exercícios de fixação 
Questão 1 - C 
Justificativa: Exemplos de repositórios são o OASIS ebXML e UDDI, tratando de 
ferramentais onde podem ser armazenados e gerenciados artefatos como XML 
Schemas e WSDL. Estes repositórios não tratam de aspectos relacionados à 
autenticação e demais elementos relacionados à segurança da plataforma. 
Quanto ao protocolo normalmente adotado, é o SOAP, e o descritor de serviços 
mais comum é o WSDL. 
 
Questão 2 - D 
Justificativa: Apenas a afirmativa IV está incorreta. Um termo muito utilizado 
em termos de programação é "acoplamento ", que trata do nível de 
interdependência entre os módulos de um sistema. Uma das características do 
SOA é justamente o baixo acoplamento, e o módulo é considerado coeso 
quando possui uma atividade bem definida e um baixo acoplamento. 
 
Questão 3 - B 
Justificativa: Apesar de todas as características apresentadas serem desejáveis 
em um ambiente SOA, a independência de plataforma é denominada 
neutralidade. 
 
Questão 4 - C 
Justificativa: A interoperabilidade é uma premissa básica para o SOA, porém 
não faz parte dos aspectos de segurança desejados, como as demais opções, 
inclusive aumentando a complexidade para que essas sejam implementadas 
efetivamente. 
 
 
 
 
 ARQUITETURA DA INFORMAÇÃO 22 
Questão 5 - E 
Justificativa: Apesar de todas as características apresentadas serem desejáveis 
em um ambiente SOA, esta gestão de papéis e da boa utilização do ambiente é 
denominada governança. 
 
Questão 6 - E 
Justificativa: O que garante a grande conectividade em um ambiente SOA, 
viabilizando inclusive o reuso de sistemas legados, é a presença do ESB 
(Enterprise Service Bus), apoiado por diversos tipos de Middleware. 
 
Questão 7 - E 
Justificativa: Apenas o JDBC não poderia ser considerado um conector típico 
para SOA. Apesar de ser um middleware para acesso a bases de dados, o SOA 
se preocupa com o acesso e orquestração de serviços, não tendo como objetivo 
o acesso direto aos dados de uma determinada base. Este acesso seria 
intermediado por um componente como o JEE ou Web Service. 
 
Questão 8 - B 
Justificativa: No caso do SOA é utilizada a modernização do tipo "caixa preta", a 
qual envolve apenas a análise de entradas e saídas do sistema legado dentro 
de um contexto operacional, de forma a identificar as interfaces desse sistema, 
ou seja, aproveitando os serviços oferecidos pelo mesmo. Não ocorre qualquer 
tipo de refatoramento, o que alteraria o código original, nem de extensões na 
linguagem original, tipicamente por herança, como ocorre na modernização 
"caixa branca". Finalmente, o uso de SOA é justificado em parte pela 
impossibilidade de substituição do sistema legado. 
 
Questão 9 - E 
Justificativa: Incialmente, CORBA, RPC e RMI estariam relacionados à conexão 
com serviços distribuídos, alguns deles considerados legados, e as Mensagerias 
estão relacionadas ao tratamento de solicitações de forma assíncrona. 
 
 ARQUITETURA DA INFORMAÇÃO 23 
Finalmente, um elemento de grande utilização dentro do ambiente SOA é a 
conexão com LDAP (Lightweight Directory Access Protocol), o que pode ser 
interessante para a gestão de certificados digitais e da segurança em conjunto 
com tecnologias como o JAAS (Java Authentication and Authorization Service). 
 
Questão 10 - C 
Justificativa: As opções II e IV estão incorretas. Um provedor pode ser 
consumidor de outro provedor, e mesmo que um Web Service possa ser 
disponibilizado diretamente, sem o uso do Broker, o ideal é que o faça através 
de outro Web Service disponibilizado pelo mesmo, de forma a não diminuir os 
aspectos de segurança e governança da arquitetura orientada a serviços.