ARQUITETURA ORIENTADA A SERVIÇOS - SOA E WEBSERVICES

Prévia do material em texto

ARQUITETURA ORIENTADA A SERVIÇOS - SOA E WEBSERVICES 1 
Apresentação ............................................................................................................................ 5 
Aula 1: Interoperabilidade - Necessidades e Conceitos ................................................ 6 
Introdução ............................................................................................................................. 6 
Conteúdo ................................................................................................................................ 7 
Histórico da integração de sistemas .............................................................................. 7 
Fatores considerados na escolha de COTS .................................................................. 8 
Integração via banco de dados ....................................................................................... 9 
Integração via protocolo ................................................................................................ 11 
Interoperabilidade ........................................................................................................... 13 
Padronização de interfaces ........................................................................................... 14 
Independência de fornecedores ................................................................................... 16 
Atividade proposta .......................................................................................................... 18 
Referências........................................................................................................................... 18 
Exercícios de fixação ......................................................................................................... 19 
Chaves de resposta ..................................................................................................................... 23 
Aula 2: Arquitetura Voltadas para Interoperabilidade ................................................ 25 
Introdução ........................................................................................................................... 25 
Conteúdo .............................................................................................................................. 26 
High level architecture .................................................................................................... 26 
HLA e RTI ........................................................................................................................... 27 
Mensagerias ...................................................................................................................... 32 
Fila ....................................................................................................................................... 33 
Tópicos .............................................................................................................................. 34 
Utilização de mensagerias ............................................................................................. 35 
Message driven bean ....................................................................................................... 36 
Atividade proposta .......................................................................................................... 38 
Referências........................................................................................................................... 38 
Exercícios de fixação ......................................................................................................... 39 
Chaves de resposta ..................................................................................................................... 43 
Aula 3: Processamento Distribuído com RPC e RMI ..................................................... 45 
Introdução ........................................................................................................................... 45 
Conteúdo .............................................................................................................................. 46 
Processamento paralelo ................................................................................................. 46 
 
 ARQUITETURA ORIENTADA A SERVIÇOS - SOA E WEBSERVICES 2 
Processamento distribuído ............................................................................................ 48 
RPC (Remote Procedure Call) ......................................................................................... 50 
RM(Remote Method Invocation) .................................................................................... 54 
Marshalling e Unmarshalling .......................................................................................... 57 
Serviços de nomes e diretórios ..................................................................................... 58 
Atividade proposta .......................................................................................................... 59 
Referências........................................................................................................................... 59 
Exercícios de fixação ......................................................................................................... 60 
Chaves de resposta ..................................................................................................................... 64 
Aula 4: Objetos Distribuído com CORBA e JEE .............................................................. 66 
Introdução ........................................................................................................................... 66 
Conteúdo .............................................................................................................................. 67 
Objetos distribuídos ........................................................................................................ 67 
CORBA ............................................................................................................................... 69 
RMI-IIOP ............................................................................................................................ 71 
Java Enterprise Edition .................................................................................................... 74 
Chamada de JEE por ferramentas CORBA ................................................................. 78 
Atividade proposta .......................................................................................................... 83 
Referências........................................................................................................................... 83 
Exercícios de fixação ......................................................................................................... 84 
Chaves de resposta ..................................................................................................................... 88 
Aula 5: Tecnologias Voltadas para XML .......................................................................... 91 
Introdução ........................................................................................................................... 91 
Conteúdo .............................................................................................................................. 92 
Sintaxe XML ....................................................................................................................... 92 
Documento XML .............................................................................................................. 94 
Entidades ........................................................................................................................... 96 
Exemplo da W3C ..............................................................................................................97 
Formas gramaticais em XML ......................................................................................... 99 
Linguagens de transformação .................................................................................... 100 
XSLT .................................................................................................................................. 101 
XSL-FO ............................................................................................................................. 103 
Outras tecnologias XML ................................................................................................ 106 
Atividade proposta ........................................................................................................ 106 
Referências......................................................................................................................... 107 
Exercícios de fixação ....................................................................................................... 108 
 
 ARQUITETURA ORIENTADA A SERVIÇOS - SOA E WEBSERVICES 3 
Chaves de resposta ................................................................................................................... 111 
Aula 6: Interoperabilidade com XML - RPC e Web Services ..................................... 114 
Introdução ......................................................................................................................... 114 
Conteúdo ............................................................................................................................ 115 
XML-RPC .......................................................................................................................... 115 
Implementação em Java .............................................................................................. 118 
SOAP ................................................................................................................................. 119 
Web Services ................................................................................................................... 122 
SOAP Web Services ........................................................................................................ 122 
UDDI ................................................................................................................................. 124 
Criação de SOAP Web Services em Java .................................................................. 125 
Criação de Cliente dotNet ........................................................................................... 126 
Sistemas B2B e B2C ....................................................................................................... 127 
Atividade proposta ........................................................................................................ 128 
Referências......................................................................................................................... 129 
Exercícios de fixação ....................................................................................................... 130 
Chaves de resposta ................................................................................................................... 134 
Aula 7: Arq. Orientadas a Serviços - Conceitos e Definições ................................... 137 
Introdução ......................................................................................................................... 137 
Conteúdo ............................................................................................................................ 138 
Princípios do SOA .......................................................................................................... 138 
Conceitos de arquitetura orientada a serviço .......................................................... 140 
Governança e Segurança ............................................................................................. 141 
Telas sobre governança ............................................................................................... 142 
Aspectos de segurança ................................................................................................. 143 
Integração e uso de tecnologias legadas .................................................................. 145 
Uso de SOA ..................................................................................................................... 146 
Uso de Web Services ...................................................................................................... 149 
Atividade proposta ........................................................................................................ 151 
Referências......................................................................................................................... 151 
Exercícios de fixação ....................................................................................................... 152 
Chaves de resposta ................................................................................................................... 156 
Aula 8: Arq. Orientadas a Serviços - ESB, BPMN e BPEL ............................................ 159 
Introdução ......................................................................................................................... 159 
Conteúdo ............................................................................................................................ 159 
ESB e middleware ........................................................................................................... 159 
 
 ARQUITETURA ORIENTADA A SERVIÇOS - SOA E WEBSERVICES 4 
Metodologia de comunicação .................................................................................... 161 
Adoção de um ESB ........................................................................................................ 162 
Aplicação do ESB ........................................................................................................... 163 
Orquestração de serviços............................................................................................. 166 
BPMN ................................................................................................................................ 167 
Evento .............................................................................................................................. 167 
Atividade .......................................................................................................................... 168 
Gateway ........................................................................................................................... 169 
Pool e Lane ...................................................................................................................... 169 
BPEL .................................................................................................................................. 171 
Atividade proposta ........................................................................................................ 176 
Referências......................................................................................................................... 177 
Exercícios de fixação ....................................................................................................... 178 
Chaves de resposta ................................................................................................................... 182 
Conteudista ........................................................................................................................... 185 
 
 
 ARQUITETURA ORIENTADA A SERVIÇOS - SOA E WEBSERVICES 5 
Conceito de arquitetura da informação. Metodologia de arquitetura da 
informação para websites. Organização do conteúdo,Sistema de navegação, 
Sistema de rotulagem e busca. Estudo de usuários e do ambiente. Testes de 
usabilidade. Modelagem. Conceituação e visão macroscópica de sites. 
Representação: sitegrama, wireframes, etc. Implentação de sites. 
 
Sendo assim, essa disciplina tem como objetivos: 
1. Compreender a importância e organização do fluxo de informação visando 
torná-la útil através de planejamento e mapeamento visual e contextual, 
assegurando a facilidade de utilização em um sistema de aplicação local ou 
web. 
2. Conhecer um pouco da história da informação na vida das pessoas e das 
organizações. 
3. Compreender as semelhanças e diferenças entre a arquitetura convencional 
e na construção de sistemas computacionais. 
4. Conhecer conceito e atributos de usabilidade. 
5. Compreender a importância da arquitetura da informação, o conhecimento 
de seus componentes e o esquema de organização na criação de websites. . 
6. Conhecer a importância de design estrutural de ambientes de informação 
compartilhados. 
 
 
 ARQUITETURA ORIENTADA A SERVIÇOS - SOA E WEBSERVICES 6 
Introdução 
A necessidade de integração entre plataformas heterogêneas sempre foi uma 
necessidade nas áreas tecnológicas; e, no decorrer de várias décadas, métodos 
cada vez mais especializados em termos de hardware e software foram 
evoluindo para que tal necessidade fosse suprida, permitindo o aumento do 
reuso, diminuição de custos e melhoria das possibilidades de manutenção 
devido à obsolescência. 
 
Esta aula visa demonstrar os elementos históricos que trouxeram essa 
necessidade à tona e quais metodologias básicas foram implementadas para 
esse tipo de integração, culminando com o atual conceito de interoperabilidade. 
 
 
Objetivo: 
1. Entender as metodologias primárias de integração e problemas relacionados 
a elas; 
2. Compreender o conceito de interoperabilidade e técnicas atuais para a sua 
obtenção. 
 
 
 
 
 
 
 
 
 
 
 
 
 ARQUITETURA ORIENTADA A SERVIÇOS - SOA E WEBSERVICES 7 
Conteúdo 
 
Histórico da integração de sistemas 
Com a expansão dos elementos tecnológicos no decorrer da história, 
começaram a aparecer grandes conjuntos de dados independentes, os quais 
não se comunicavam, gerando uma grande redundância de informações e 
desperdício de poder de processamento. 
 
Muitos projetos apresentavam características semelhantes, mas, como não 
existiam interfaces comuns, ocorria um grande retrabalho na construção de 
novos produtos e bases de dados. 
 
Em meados da década de 90, com a expansão dos sistemas, começaram a ser 
oferecidas diferentes formas padronizadas de armazenar, recuperar e processar 
dados de origem externa aos aplicativos. Através de conversores de dados, os 
arquivos de um determinado fabricante eram convertidos para um determinado 
formato, de forma que outro fabricante pudesse ler. Esse processo surgiu da 
necessidade de compartilhamento de dados entre aplicativos distintos. 
 
Essa não é uma preocupação nova. Na área de engenharia, sempre ocorreram 
problemas quanto à obsolescência e preocupações com manutenções. Não é 
raro o fato de um fornecedor falir ou um componente sair de linha, 
encarecendo demasiadamente a continuidade do funcionamento de 
determinado sistema. 
 
Para baratear e agilizar a produção de um novo sistema de engenharia são 
utilizados elementos funcionais prontos para uso, denominados COTS 
(commercial off-the-shelf), os quais tratam de componentes comerciais 
reutilizáveis, testados e aceitos pelo mercado – e integráveis com relativa 
facilidade para a construção de produtos maiores. 
 
 
 ARQUITETURA ORIENTADA A SERVIÇOS - SOA E WEBSERVICES 8 
Mesmo que um COTS apresente meios de integração padronizados, essa 
integração acrescenta alguma complexidade ao sistema, pois o grande desafio 
no uso de COTS é adequar sua utilização às necessidades do sistema sem 
alterar o componente em si. 
 
Esses componentes, ao apresentarem interfaces padronizadas, podem ser 
substituídos por outros equivalentes, independentemente de fornecedor, de 
forma a viabilizar a continuidade do funcionamento do sistema, mesmo que 
adversidades variadas venham a ocorrer no mercado. 
 
Desse modelo surge a ideia básica por trás da interoperabilidade, a qual pode 
ser definida como a capacidade de elementos heterogêneos se comunicarem, 
compartilhando dados e complementando funcionalidades. 
 
Na área da informática, as atuais arquiteturas de software divididas em 
camadas, como a MVC (model, view e control), viabilizaram a criação de COTS 
para cada uma das camadas, como os diversos frameworks existentes. 
 
Fatores considerados na escolha de COTS 
A plataforma Java sempre trabalhou com esse conceito, definindo 
especificações para diversas áreas, como criptografia, EJB (Enterprise Java 
Beans), e muitos outros, nos quais diferentes fornecedores de componentes 
devem seguir essas especificações de forma a permitir uma fácil permutação 
entre ambientes distintos. Acompanhe: 
 
Quanto à longevidade do componente, existem preocupações acerca da 
reposição e atualização devido à obsolescência, devendo-se levar em conta a 
existência de similares e o custo ou esforço efetivo para a substituição do 
componente no decorrer do ciclo de vida do sistema. 
 
Além desses, outros fatores considerados na escolha de COTS, tanto software 
como hardware, são a confiabilidade, manutenibilidade, eficiência e eficácia. 
 
 ARQUITETURA ORIENTADA A SERVIÇOS - SOA E WEBSERVICES 9 
Ainda com relação à longevidade, é comum, nas arquiteturas orientadas a 
serviço da atualidade, existirem meios de comunicação com tecnologias 
legadas, como sistemas CORBA, diminuindo o custo de implementação de 
novas funcionalidades ao reutilizar os serviços já existentes em conjunto com 
serviços criados através de novas tecnologias para a complementação de 
tarefas mais complexas. 
 
Ainda nesta disciplina, observaremos as diversas formas de interoperabilidade 
utilizadas de forma comercial, culminando na definição e uso de arquiteturas 
orientadas a serviço. 
 
Integração via banco de dados 
O primeiro nível de integração obtido na informática foi com o 
compartilhamento de informações em bancos de dados comerciais, 
particularmente os bancos relacionais, como Oracle, Informix, DB2, SQL Server, 
entre muitos outros. 
 
As ferramentas de programação antigas tinham bibliotecas de acesso para 
bancos de dados específicos, o que aumentava muito a dependência do código-
fonte em relação ao fornecedor do banco de dados. Posteriormente, a camada 
de comunicação com o banco, assim como outros tipos de back-end, foi isolada 
das demais, definindo-se o que veio a ser chamado de middleware. 
 
Essa dependência da ferramenta em relação ao banco em termos de 
programação, quando eram utilizados componentes específicos de acesso ao 
invés de um middleware, acaba causando grande dependência do código e alto 
acoplamento, o que acaba restringindo o uso de um determinado fornecedor de 
banco ou ao menos dificultando a sua substituição, como era o caso do PHP 
com MySQL, ou do Clipper com arquivos DBF. 
 
Na abordagem atual, de um lado, temos o back-end, representado pelos 
diversos tipos de bancos de dados; e de outro, o front-end, onde se 
 
 ARQUITETURA ORIENTADA A SERVIÇOS - SOA E WEBSERVICES 10 
apresentam ferramentas de desenvolvimento, como o Java, C# e Delphi. 
Intermediando os dois lados, cada front-end adota uma plataforma de 
middleware de dados própria, como JDBC (Java Database Conectivity), ODBC 
(Open Database Conecivity) ou BDE (Borland Database Engine), todas essas 
voltadas para a intermediação entre o front-end e os diversos back-ends de 
diferentes fornecedores. 
 
Com essa modificação na concepção dos sistemas, hoje é possível programar 
da mesma forma para diversos bancos de dados diferentes dentro de cada 
ferramenta; e, se utilizado o SQL ANSI, o fornecedor do banco torna-seirrelevante em termos de código. 
 
Vantagens que essa abordagem inclui: 
 
 
 
Infelizmente, nem tudo é positivo, e alguns pontos negativos devem ser 
considerados. São eles: 
 
• O uso de SQL proprietário, como PL-SQL, pode diminuir a portabilidade do 
banco. 
• Sem o tratamento adequado por todos os front-ends, os dados poderão 
apresentar inconsistências. 
• Os métodos transacionais no nível do aplicativo podem sofrer o impacto dos 
demais sistemas que compartilham o banco. 
 
 ARQUITETURA ORIENTADA A SERVIÇOS - SOA E WEBSERVICES 11 
• Qualquer alteração nos metadados irá trazer consequências para os diversos 
front-ends. 
• Se um sistema altera o formato de gravação de um campo, como de real para 
monetário, os outros sistemas podem parar de funcionar, dependendo do 
banco de dados utilizado. 
 
 
 
Atenção 
 Apesar dos problemas apresentados, o uso de middleware 
facilitou muito o acesso a bancos de dados e viabilizou um 
primeiro nível de integração entre sistemas, sendo esse ao nível 
dos dados. 
 
O termo middleware não se restringe ao uso de banco de dados, 
podendo tratar da conexão com mensagerias, sistemas de 
arquivos e outros. Ele será frequentemente utilizado nesta 
disciplina, sendo melhor detalhado posteriormente. 
 
Integração via protocolo 
Com o uso extensivo de redes na atualidade, é fácil perceber que o uso de 
protocolos de comunicação para viabilizar integração entre sistemas é uma 
realidade, inclusive levando a conceitos como conectividade na definição das 
características de sistemas operacionais móveis, entre outros. 
 
Em termos gerais, o protocolo é a formalização da comunicação e transferência 
de dados entre dois sistemas computacionais. Ele define formato de chamada e 
reposta, bem como comandos, tipos de dados aceitos e informações 
complementares. 
 
 
 ARQUITETURA ORIENTADA A SERVIÇOS - SOA E WEBSERVICES 12 
Definido o protocolo, não importa quais tecnologias serão utilizadas para 
implementar ambos os lados da comunicação, como Java e Dot Net, desde que 
ambas sejam capazes de acessar a rede e trocar informações no formato 
especificado. 
 
Um protocolo pode ser definido em diversas camadas de rede, segundo o 
modelo OSI, como: 
 
 
(Figura representativa das camadas de rede) 
 
Nos dias atuais, é comum a troca de dados entre dispositivos móveis via 
Bluetooth, ou que esse mesmo dispositivo acesse um servidor HTTP hospedado 
em ambiente de nuvem. 
 
Outro exemplo são os diversos programas clientes de Telnet, criados nas mais 
diversas linguagens, acessando um servidor Telnet qualquer, sem precisar se 
preocupar com o fornecedor desse servidor ou o sistema operacional sobre o 
qual executa. 
 
Como o foco maior do mercado são as redes TCP-IP, o uso de Sockets, onde é 
associado o endereço IP a uma porta que caracteriza a aplicação, tornou-se 
comum na criação de sistemas remotos; e, com isso, foram definidos serviços 
genéricos de transferência de dados. 
 
 ARQUITETURA ORIENTADA A SERVIÇOS - SOA E WEBSERVICES 13 
 
 
Atenção 
 Com protocolos de comunicação bem definidos, duas 
plataformas distintas podem trabalhar em conjunto, resumindo o 
acoplamento dos aplicativos à simples aceitação do protocolo 
formal. 
 
Interoperabilidade 
Os sistemas, em geral, têm evoluído muito, e várias soluções prontas 
incorporam processos complexos que podem ser disponibilizados para novos 
desenvolvimentos. Para tal, esses sistemas devem se comunicar com facilidade, 
segundo o conceito de interoperabilidade. 
 
Um sistema interoperável deve permitir acesso a suas funcionalidades segundo 
padrões de comunicação abertos, aceitos pelo mercado, de forma a tornar 
transparente, ou quase, o processo de integração. 
 
Embora seja antigo o interesse da engenharia de sistemas pelo tema, 
inicialmente a integração ocorria apenas no nível dos dados, com a definição de 
formatos e meios de armazenamentos comuns; mas os sistemas foram se 
tornando mais complexos, novos padrões de comunicação com o meio externo 
foram definidos, e a interoperabilidade evoluiu para o nível de processos e 
serviços. 
 
O interesse de empresas e órgãos governamentais pelo tema pode ser 
observado pelo grande número de normas existentes com o objetivo de trazer 
padronização aos elementos envolvidos nas mais diversas fases do ciclo de vida 
dos sistemas. 
 
 
 ARQUITETURA ORIENTADA A SERVIÇOS - SOA E WEBSERVICES 14 
Um pequeno exemplo de interoperabilidade foi a disponibilização de DDE 
(Dynamic Data Interchange) e OLE (Object Linked and Embeded) para os 
ambientes Microsoft Windows, amplamente utilizado em seu pacote Office já há 
algumas décadas. 
 
Com a disponibilização deste tipo de funcionalidade, tornou-se muito comum 
utilizar uma planilha incorporada a um documento de texto, ou um banco de 
dados fornecendo para este editor os dados necessários para uma mala direta. 
 
Mas a interoperabilidade vai muito além disso, e o elemento principal para 
viabilizá-la seria a definição de padrões de interface abertos que permitissem a 
exposição e uso de ferramentas com o mínimo de acoplamento possível. 
 
 
Atenção 
 Quando uma metodologia ou ferramental tecnológico promete 
diminuir o acoplamento, isso significa dizer que os componentes 
e protocolos viabilizam uma independência bem maior por parte 
de cada participante nas diversas transações. 
 
Padronização de interfaces 
A busca de interfaces com baixo acoplamento para acesso a serviços e 
componentes passou por grandes evoluções no decorrer do tempo. Um 
exemplo de interface padronizada visando à interoperabilidade em termos de 
software é a evolução da tecnologia OLE, já citada anteriormente, 
posteriormente servindo de base para componentes Active X e COM 
(Component Object Model). 
 
As plataformas que viabilizavam a criação desses tipos de componentes 
precisam se preocupar apenas em atender à interface de programação 
 
 ARQUITETURA ORIENTADA A SERVIÇOS - SOA E WEBSERVICES 15 
formalmente definida pela Microsoft, a qual trabalha necessariamente com as 
interfaces IUnknow e IDispatch. 
 
Com o uso dessa interface-padrão de programação e ativação de objetos 
Microsoft, ferramentas como Delphi e Visual Basic passaram a criar objetos 
intercambiáveis dentro do ambiente Windows. 
 
Em termos de redes, inicialmente as interfaces eram baseadas na simples 
aceitação de protocolos formais, mas posteriormente serviços de rede se 
especializaram, levando à adoção de padrões para a execução remota de 
procedimentos. 
Exemplos de padronização e especialização de interfaces para execução em 
redes seriam o RPC (Remote Procedure Call) e o RMI (Remote Method 
Invocation), preocupados com a padronização da chamada a procedimentos e 
métodos de forma remota. 
 
Paralelamente, surgiram sistemas de mensageria que permitiam trabalhar de 
forma assíncrona, com uso de tecnologias distintas, pelas quais o acoplamento 
se restringe ao canal de comunicação entre os aplicativos. 
 
Os ambientes de objetos distribuídos começaram a ser utilizados, com a 
padronização dos protocolos de acesso e regras para escrita das interfaces, 
sem foco em linguagens específicas, pois o objetivo é as plataformas serem 
acessadas por qualquer um que siga as regras. 
 
Apesar de muitas iniciativas terem sido tomadas por diversos fornecedores para 
a construção de plataformas de objetos distribuídos, a complexidade para a 
construção desse tipo de ambiente fez com que apenas alguns se destacassem. 
Alguns exemplos de plataformas de objetos distribuídos amplamente adotadas 
no mercado: CORBA (Common Object Request Broker Architecture), EJB 
(Enterprise Java Beans) e DCOM (Distributed Component Object Model). Todas 
essas plataformas apresentam alguns conceitos comuns e se preocupam em 
 
 ARQUITETURA ORIENTADA A SERVIÇOS - SOA E WEBSERVICES 16 
oferecer modelos padronizadas para definir a localização dos componentes eexposição da interface de serviços de cada um. 
 
Tomando como exemplo a questão do serviço de localização e registro de 
componentes, o CORBA utiliza COS Naming, enquanto o JEE trabalha com JNDI 
(Java Naming and Directory Interface). Nesse segundo, é utilizada também a 
interface padrão do Java para serviços de nomes, a qual unifica os métodos de 
nomeação de componentes, desde um EJB (Enterprise Java Bean) até um pool 
de conexões com banco de dados. Nessa mesma linha, tornaram-se comuns no 
mercado os web services, cuja interoperabilidade é garantida pelo uso de uma 
sintaxe simples, de modo texto, com larga aceitação no mercado. 
Por fim, o mercado passa adotar arquiteturas orientadas a serviços, por meio 
das quais um grande conjunto de ferramentas, como middlewares, 
orquestradores de serviço, disponibilização de web services, acesso a 
tecnologias legadas, entre muitos outros elementos, garantem o melhor nível 
de reuso e interoperabilidade dentro de um ambiente corporativo. 
 
Além dos exemplos comercialmente conhecidos e que apresentam áreas fins 
bastante genéricas, em muitos nichos específicos tais interfaces foram 
definidas, como o protocolo HL7 (Health Level 7 ), protocolo internacionalmente 
aceito na área de saúde, e a High Level Architecture, na área de simulações 
militares. 
 
Independência de fornecedores 
A área de hardware já trabalha há muito tempo para padronizar as interfaces, 
de forma a permitir que diferentes fornecedores possam construir aparatos 
similares, mantendo sempre a compatibilidade com o sistema principal, como é 
o caso das interfaces USB (universal serial bus). 
 
Hoje em dia, é muito mais fácil obter um meio de armazenamento compatível 
com vários computadores, ao contrário do que ocorria nos primeiros 
 
 ARQUITETURA ORIENTADA A SERVIÇOS - SOA E WEBSERVICES 17 
computadores pessoais, quando era comum os fabricantes trabalharem com 
interfaces distintas, até mesmo para evitar a suposta concorrência. 
 
Também na área de software essa independência de fornecedores foi bastante 
almejada, pois, com as possibilidades de integração e definição de interfaces 
padronizadas, mais fornecedores se animaram com a possibilidade de atingir 
nichos específicos, reutilizáveis em vários sistemas, como nos casos de bancos 
de dados e mensagerias. 
 
A definição de arquiteturas e metodologias independentes de plataforma ou 
fornecedores específicos viabiliza a concorrência direta, causando um efeito no 
mercado de aumento de qualidade e diminuição do custo, estimulando também 
a melhoria dos meios de produção nas áreas relacionadas a hardware. 
 
Um exemplo utilizado para promover essa independência, já citado 
anteriormente, é o uso de middleware, pois, com a adoção de uma camada 
intermediária entre front-end e back-end, torna-se praticamente irrelevante o 
fornecedor escolhido para o back-end. É claro que a qualidade do componente 
selecionado poderá variar, e o uso em ambientes críticos direcionará a escolha 
para um grupo menor de fornecedores. 
 
As mensagerias com formato padronizado de mensagem também permitem a 
substituição de seu fornecedor, fazendo com que aspectos de segurança e 
robustez passem a ser analisados frente ao custo da implantação de uma 
mensageria específica. 
 
Várias soluções de código aberto também passaram a ser utilizadas, o que foi 
observado muito facilmente na área de banco de dados com a adoção de 
MySQL por diversas empresas. 
 
Em termos de servidores, a padronização dos componentes JEE, bem como 
CORBA, permite que seja escolhido um entre vários servidores com 
 
 ARQUITETURA ORIENTADA A SERVIÇOS - SOA E WEBSERVICES 18 
características similares, como é o caso do GlassFish e do JBoss. Por fim, com 
dados transitando em formato XML, como no caso do protocolo SOAP, ocorre 
um vertiginoso aumento do leque de ferramentas que podem ser utilizadas 
tanto no cliente quanto no servidor, permitindo a escolha dos mais diversos 
fornecedores em termos de servidores e ambientes de desenvolvimento. 
 
 
Atenção 
 A cada vez que uma nova possibilidade de integração surge, 
novas possibilidades de desenvolvimento se abrem, novos 
fornecedores surgem, e acabam aparecendo também produtos e 
metodologias para aumentar as funcionalidades da própria 
plataforma de integração. 
 
Atividade proposta 
Como atividade de fixação, efetue uma pesquisa acerca de metodologias 
abertas de integração entre sistemas e tecnologias que visam a 
interoperabilidade. 
 
Referências 
Cople, D. Um framework para Análise de Custo de Ciclo de vida baseado em 
reuso e interoperabilidade, UFF, 
http://www.bdtd.ndc.uff.br/tde_arquivos/29/TDE-2011-03-
01T134340Z-2764/Publico/Denis%20Cople-Tese.pdf 
 
Rowley, K. Understanding Software Interoperability in a Technology-Supported 
System of Education, 
https://net.educause.edu/ir/library/pdf/CEM9535.pdf 
 
 
 
 
 ARQUITETURA ORIENTADA A SERVIÇOS - SOA E WEBSERVICES 19 
 
 
 
 
Exercícios de fixação 
Questão 1 
Uma prática que se tornou comum na área de engenharia foi a adoção de 
COTS. Qual das características abaixo NÃO pode ser considerada como 
referente a um componente deste tipo? 
a) Apresentam meios de integração padronizados. 
b) São componentes comerciais reutilizáveis. 
c) Baseiam-se em padrões abertos de interface. 
d) Visam proteger tecnologias proprietárias. 
e) Facilitam a manutenção do sistema, apesar de acrescentarem alguma 
complexidade em termos de integração. 
 
Questão 2 
Qual conceito pode ser definido como "a capacidade de elementos 
heterogêneos se comunicarem, compartilhando dados e complementando 
funcionalidades "? 
a) Middleware 
b) Interoperabilidade 
c) Front-End 
d) Back-End 
e) COTS 
 
Questão 3 
Um protocolo de rede pode ser considerado como um elemento bastante 
primário de interoperabilidade, e o mesmo pode ser definido em diversas 
camadas da rede, segundo o modelo OSI. Assinale a alternativa INCORRETA. 
a) O protocolo SMTP atua na camada de aplicação. 
b) O protocolo UDP atua na camada de transporte. 
 
 ARQUITETURA ORIENTADA A SERVIÇOS - SOA E WEBSERVICES 20 
c) O protocolo TCP/IP atua na camada de transporte. 
d) O protocolo ICMP atua na camada de rede. 
e) O protocolo HTTP atua na camada de aplicação. 
 
Questão 4 
Considere as afirmativas abaixo acerca de middleware: 
I – Permite transparência com relação ao fabricante do banco de dados. 
II – O uso de SQL proprietário não diminui a portabilidade com relação ao tipo 
de banco de dados. 
III – Faz a mediação entre Front-End e Back-End. 
IV – Permite acessar bancos de dados legados de tecnologias legadas a partir 
de novas ferramentas de desenvolvimento. 
Quantas opções estão corretas? 
a) Nenhuma 
b) 1 
c) 2 
d) 3 
e) 4 
 
Questão 5 
Existem preocupações acerca da reposição e atualização devido a 
obsolescência, devendo ser levado em conta a existência de similares e o custo 
ou esforço efetivo para a substituição do mesmo no decorrer do ciclo de vida do 
sistema. Para satisfazer a este tipo de preocupação, qual fator deve ser 
considerado na escolha de COTS? 
a) Eficiência 
b) Eficácia 
c) Longevidade 
d) Confiabilidade 
e) Manutenibilidade 
 
Questão 6 
 
 ARQUITETURA ORIENTADA A SERVIÇOS - SOA E WEBSERVICES 21 
Entre os elementos abaixo, qual deles NÃO é um exemplo de interface 
padronizada entre linguagens de programação? 
a) COM 
b) ActiveX 
c) RPC 
d) RMI 
e) BDE 
 
Questão 7 
Sobre as tecnologias OLE e DDE, o que podemos afirmar? 
a) Voltadas para a integração entre o Delphi e o banco de dados. 
b) Tecnologias que funcionam independente do sistema operacional. 
c) Permitem a incorporação de uma planilha em um documento texto no pacote 
Microsoft Office. 
d) Foram ambas criadas pela Oracle. 
e) São a base do protocolo SOAP. 
 
Questão 8 
Considerando-se o CORBA, os EJBs e o DCOM, estes são exemplos de que tipo 
de tecnologia? 
a) GramáticasXML 
b) Objetos Distribuídos 
c) Sistemas Operacionais 
d) Tecnologias Proprietárias 
e) Componentes de Hardware 
 
Questão 9 
Qual tecnologia permite um comportamento assíncrono, com acoplamento 
muito fraco, baseado apenas nas mensagens enviadas pelo canal de 
comunicação? 
a) Mensageria 
b) RPC 
 
 ARQUITETURA ORIENTADA A SERVIÇOS - SOA E WEBSERVICES 22 
c) RMI 
d) CORBA 
e) Banco de dados 
 
Questão 10 
Qual a sintaxe que trouxe uma vertiginosa evolução dos modelos de 
interoperabilidade, sendo de grande utilização nas arquiteturas orientadas a 
serviço da atualidade? 
a) Java 
b) HTML 
c) XML 
d) Delphi 
e) C++ 
 
 
 
 ARQUITETURA ORIENTADA A SERVIÇOS - SOA E WEBSERVICES 23 
Aula 1 
Exercícios de fixação 
Questão 1 - D 
Justificativa: Estes componentes, ao apresentarem interfaces padronizadas, 
podem ser substituídos por outros equivalentes, independente de fornecedor. 
 
Questão 2 - B 
Justificativa: A ideia básica por trás da interoperabilidade pode ser definida 
como a capacidade de elementos heterogêneos se comunicarem, 
compartilhando dados e complementando funcionalidades. Quanto ao 
Middleware e COTS, estes viabilizam a interoperabilidade em determinados 
contextos restritos. 
 
Questão 3 - C 
Justificativa: Esta é uma confusão comum em diversos blogs e discussões 
acerca de redes. Em verdade são dois protocolos: o TCP atuando na camada de 
transporte, e o IP atuando na camada de rede. Não existe o protocolo TCP/IP. 
 
Questão 4 - D 
Justificativa: A opção II está incorreta, pois para manter a portabilidade de 
banco de dados deve ser utilizado apenas o SQL ANSI. As demais opções estão 
corretas. 
 
Questão 5 - C 
Justificativa: O fator que satisfaz à necessidade apresentada é a longevidade, 
pois eficiência e eficácia referem-se às características funcionais próprias do 
sistema, e confiabilidade e manutenibilidade referem-se a características de 
manutenção pontuais dos COTS, sem uma visão de atualização e reposição no 
decorrer do tempo. 
 
 
 ARQUITETURA ORIENTADA A SERVIÇOS - SOA E WEBSERVICES 24 
Questão 6 - E 
Justificativa: Enquanto as demais opções permitem o uso de linguagens de 
programação distintas na implementação dos componentes, o BDE trata de um 
middleware exclusivo do Delphi para acesso a banco de dados. 
 
Questão 7 - C 
Justificativa: Quem é voltado exclusivamente para integração entre Delphi e 
banco de dados é o BDE. Quanto ao OLE e DDE, estas são tecnologias da 
Microsoft, que executam em ambiente Windows, e são muito utilizadas na 
integração entre os softwares do pacote Microsoft Office. Quanto ao protocolo 
SOAP, ele é baseado em sintaxe XML. 
 
Questão 8 - B 
Justificativa: Os três são exemplos de objetos distribuídos (software), sendo 
que o CORBA não é tecnologia proprietária. Nenhum dos exemplos define uma 
gramática XML e, por fim, não são sistemas operacionais, como seria o caso do 
Windows e do Linux. 
 
Questão 9 - A 
Justificativa: O conceito exposto é a própria definição de sistemas de 
mensageria, além de ser a única das cinco tecnologias citadas que viabiliza 
nativamente o comportamento assíncrono. 
 
Questão 10 - C 
Justificativa: As arquiteturas orientadas a serviço da atualidade trabalham muito 
com a sintaxe XML, particularmente com o uso do mesmo através do protocolo 
SOAP. Como características fortes da sintaxe podemos ressaltar a facilidade de 
manuseio por qualquer linguagem e a transparência na transmissão através de 
firewalls. 
 
 
 
 
 ARQUITETURA ORIENTADA A SERVIÇOS - SOA E WEBSERVICES 25 
Introdução 
Com a grande diversidade de sistemas e fornecedores de componentes, a 
interoperabilidade torna-se um diferencial para as ferramentas, e algumas 
arquiteturas passam a trabalhar visando a esse princípio. 
 
Essa aula irá apresentar uma arquitetura baseada em interoperabilidade 
utilizada na área de simulações militares, a qual é denominada HLA (high level 
architecture), bem como trazer conhecimentos acerca do uso de mensagerias. 
 
Estes são dois exemplos de arquiteturas voltadas para reuso: interoperabilidade 
e baixo acoplamento. 
 
Objetivo: 
1. Compreender os conceitos gerais e características da HLA; 
2. Entender o funcionamento de mensagerias e sua utilização com Java. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 ARQUITETURA ORIENTADA A SERVIÇOS - SOA E WEBSERVICES 26 
Conteúdo 
 
High level architecture 
A área de simuladores sempre apresentou grande complexidade. E muitas 
soluções para os mesmos problemas seguiam caminhos diferentes, impedindo 
que tais soluções trabalhassem em conjunto. 
 
1- Muitas simulações complexas e de grande porte acabam por envolver várias 
simulações individuais menores. 
2 - As simulações menores eram construídas de forma heterogênea, tanto em 
termos do tipo de simulação quanto em relação às funcionalidades dos 
componentes. 
3 - Muitos componentes da simulação já existiam, porém não eram integráveis. 
4 - Recriar um componente de simulação, além de ser caro, representa um 
risco maior em termos de testes e estabilidade. 
 
Essa não é uma preocupação nova. Como pode ser observado, a ausência de 
um ambiente interoperável e de componentes reutilizáveis acaba por encarecer 
a construção de um sistema de simulação, bem como demandar mais tempo na 
implementação. Além disso, se fossem utilizados COTS, esses já teriam passado 
por várias fases de teste, diminuindo o risco da implementação final. Partindo 
dessas necessidades, e após diversas iniciativas de integração e padronização 
de interfaces na área de simulação militares, foi definido o HLA (high level 
architecture): 
 
 Um framework genérico com a finalidade de melhorar a 
interoperabilidade e reuso de componentes de simulação. 
 
 Criado pelo Defense Modeling and Simulation Office (DMSO). 
 
 Desenvolvido inicialmente para o Departamento de Defesa dos Estados 
Unidos (DoD). 
 
 ARQUITETURA ORIENTADA A SERVIÇOS - SOA E WEBSERVICES 27 
 
 Tornou-se um padrão no ano de 2000 (IEEE Standard 1516-2000). 
 
A adoção de HLA promove o reuso de componentes de simulação que podem 
vir a ser utilizados em diferentes cenários e sistemas ao longo de sua vida útil. 
 
• Permite agrupar simulações compostas de múltiplos componentes de 
simulação; 
• Integra simulações distribuídas através de diferentes plataformas de software 
e hardware heterogêneo; 
• Reutiliza sistemas sem mudanças significantes de código ou custo maior de 
desenvolvimento; 
• Combina componentes de simulação com diversos modelos computacionais e 
representações formais. 
 
 
 
HLA e RTI 
Termos e definições do HLA: 
 
 
 ARQUITETURA ORIENTADA A SERVIÇOS - SOA E WEBSERVICES 28 
 Federate é uma aplicação com suporte a HLA que pode participar de 
uma simulação nesse ambiente. 
 
 Federation é a declaração entre federates que definem como e o que 
será simulado. 
 
 Federation execution trata de uma instância de um federation em 
execução, ou seja, a execução da simulação em si. 
 
Dentro da arquitetura do HLA é definida uma infraestrutura de execução, ou 
RTI (run-time infrastructure), que trata basicamente de um framework com as 
seguintes características: 
 
• Camada de software que fornece serviços comuns aos federates. 
• A especificação do RTI define as interfaces que os federates precisam acessar 
para obter serviços e interagir com outros federates. 
• Essa especificação também define qual interface os federates devem expor 
para que sejam reconhecidos pelos serviços e por outros federates. 
• Trabalha com tecnologias de simulação legadas, como DIS e ALSP. 
• Promove uma comunicação eficiente entre federates. 
• Separa os conceitos de simulação e comunicação. 
• Independente de linguagem ou plataforma. 
 
Os principais componentes apresentados pela RTI são: 
 
• Gestão de federation, que controla as atividades de cada federation durante a 
execução. 
• Gestão de declarações,que controla o modelo de publicação e assinatura 
para troca de informações. 
• Gestão de objetos, controlando todo o ciclo de vida e troca de mensagens 
entre esses objetos. 
 
 ARQUITETURA ORIENTADA A SERVIÇOS - SOA E WEBSERVICES 29 
• Gestão de responsáveis, ou detentores, de forma a viabilizar simulações 
cooperativas através da troca de responsabilidade sobre atributos ao longo da 
simulação. 
• Gestão de tempo a qual coordena a linha de tempo de cada federate dentro 
do eixo de tempo do federation, garantindo a preservação de causa e 
ordenação. 
• Gestão de dados distribuídos, com a transmissão eficiente de dados entre 
federates. 
• Serviços de apoio. 
 
Conheça a tabela que resume os serviços essenciais de cada componente do 
RTI: 
 
Serviços essenciais de cada componente do RTI 
 
Gestão de Federation 
- Inicialização e término da execução de Federations 
- Joining and resigning of federates 
- Pausa e reinício da execução do Federation 
- Persistência (armazenagem e recuperação) de 
Federation em execução 
Gestão de declarações 
- Publicação do objeto e classes de interação 
- Resgate de classes de interação 
- Resgate de atributos do objeto 
- Controle de alterações 
- Controle de interações 
 
 ARQUITETURA ORIENTADA A SERVIÇOS - SOA E WEBSERVICES 30 
Gestão de objetos 
- Registro e localização de objetos 
- Alteração e exposição de atributos de objetos 
- Envio e recebimento de mensagens de interação 
- Remoção de objetos 
- Manage transport/ordering 
Gestão de responsáveis 
- Assume/divest attribute ownership 
- Acquire/release attribute ownership 
- Notification of ownership changes 
Gestão de tempo 
(Federation) 
- Sincronização conservativa 
- Sincronização otimista 
- Métodos híbridos de sincronização 
- Avanço de tempo 
- Controle de tempo real 
 
(Federate) 
- Requisição de avanço de tempo 
- Notificação de avanço concedido 
- Requisição do próximo evento 
- Notificação de evento concedido 
- Gerenciamento da fila de requisições 
 
 ARQUITETURA ORIENTADA A SERVIÇOS - SOA E WEBSERVICES 31 
Gestão de dados 
distribuídos 
- Definição da área de update na publicação 
- Definição da área de interesse pelo participante 
- Gestão das áreas de roteamento (interseções) 
Serviços de apoio 
- Transformação de nome para handle 
- Transformação de handle para nome 
- Gestão do sistema de avisos 
- Manipulação de regiões 
- RTI start-up e shutdown 
 
A figura a seguir mostra resumidamente o funcionamento de uma federation. 
 
 
(Figura ilustrativa do funcionamento de um federation.) 
 
 
 ARQUITETURA ORIENTADA A SERVIÇOS - SOA E WEBSERVICES 32 
Nos dias atuais, assim como nas arquiteturas orientadas a serviço, é comum a 
adoção de web services para a comunicação na HLA. Na verdade, observando-
se as soluções apresentadas pela HLA, é fácil perceber como muitos dos 
serviços de gestão do RTI estão presentes nas arquiteturas de objetos 
distribuídas e orientadas a serviços. 
 
Mensagerias 
Uma solução para a integração de sistemas complexos com baixíssimo 
acoplamento é o uso de mensagerias. Conheça, a seguir, exemplos de 
mensagerias comumente encontradas no mercado. 
 
 
 
Podemos ter sistemas desenvolvidos em diferentes tecnologias, como Java e 
C#, cada uma com sua biblioteca de middleware para acesso à mensageria, 
nesse caso denominado MOM (message oriented middleware), trocando 
mensagens através dessa mensageria, inclusive de forma assíncrona. 
 
O princípio de escrita e leitura assíncrona é muito comum nas diversas 
tecnologias de interação social, como e-mails, mensagens em redes sociais, 
mensagens em ambientes móveis, entre muitos outros exemplos. Basicamente, 
 
 ARQUITETURA ORIENTADA A SERVIÇOS - SOA E WEBSERVICES 33 
trata-se de uma arquitetura peer-to-peer com serviço centralizado de repasse 
de mensagens recebidas e enviadas, serviços esse que administra canais 
registrados acessíveis tanto aos clientes quanto aos servidores. 
 
 
 
Um exemplo do uso de mensagerias no dia a dia de qualquer brasileiro é o 
processamento de DOCs e TEDs do sistema bancário. 
 
O que recebemos ao solicitar esse tipo de transação é um mero comprovante 
da solicitação em si, que é enviada para uma mensageria, sendo processada 
algum tempo depois pelo banco alvo, sem obrigar o usuário a esperar por esse 
processamento, ou, em termos técnicos, atuando de forma assíncrona. Existem 
dois modelos de comunicação disponíveis nesse ambiente: fila e tópico. 
 
Fila 
No modelo de fila, existem muitos destinatários e apenas um receptor, o qual 
pode ou não estar ativo no momento do envio. 
 
O receptor retira da fila a mensagem, processa-a e envia um sinal para a 
mensageria informando que já houve o consumo (acknowledgement). 
 
A fila retém a mensagem até que ela seja consumida, segundo uma ordenação 
FIFO (a primeira a entrar é a primeira a sair). 
 
 ARQUITETURA ORIENTADA A SERVIÇOS - SOA E WEBSERVICES 34 
 
(figura representativa de um modelo de Fila) 
 
Tópicos 
No modelo de tópicos, podem ocorrer vários emissores e vários receptores 
simultaneamente. Esse modelo também é denominado publish-subscribe. 
 
As mensagens são enviadas a um canal (tópico), de onde os assinantes 
poderão retirá-las. Nesse modelo, é necessário um objeto ouvinte (message 
listener) para avisar que há nova mensagem no canal. 
 
 
 ARQUITETURA ORIENTADA A SERVIÇOS - SOA E WEBSERVICES 35 
 
(figura representativa de um modelo de Tópicos) 
 
 
Utilização de mensagerias 
O uso de mensagens é indicado em situações específicas. 
 
Quando o elemento principal da comunicação é o formato da mensagem, e não 
interfaces de programação. 
 
Quando não é possível prever a disponibilidade dos componentes de ambos os 
lados, receptor ou emissor. 
 
Quando é preciso suportar comunicação assíncrona, ou seja, o emissor envia a 
informação, mesmo que o receptor não esteja ativo, e não bloqueia suas 
operações. 
 
 
 
 
 ARQUITETURA ORIENTADA A SERVIÇOS - SOA E WEBSERVICES 36 
 
Atenção 
 É muito comum a adoção de mensagerias em processos B2B 
(business to business), ou seja, na comunicação entre sistemas de 
empresas distintas, como é o caso das instituições bancárias 
brasileiras. 
 
Como as mensagerias permitem um melhor controle de acesso, 
acabam formando um canal de comunicação privado entre as 
empresas, aumentando também a segurança da comunicação entre 
elas. 
 
Na linguagem Java, o MOM é acessado pelo Java Message Service 
(JMS), uma biblioteca que consiste basicamente de interfaces a 
serem implementadas pelo fabricante do MOM, assim como ocorre 
com o JDBC. 
 
 
Message driven bean 
Na arquitetura JEE, existe um componente especializado no tratamento de 
mensagens, o qual é denominado MDB (message driven bean), e que faz uso 
do JMS para acesso a diferentes mensagerias. Os componentes do tipo MDB 
são EJBs (enterprise java beans), e, como demais componentes dessa 
arquitetura, atualmente, podem ser criados com o uso de simples código 
anotado Java. 
 
 
 ARQUITETURA ORIENTADA A SERVIÇOS - SOA E WEBSERVICES 37 
 
A anotação @MessageDriven define a classe como um MDB, configurando 
recurso acessado na mensageria, bem como o tipo de destino (fila ou tópico). 
 
A classe, por sua vez, deve implementar a interface MessageListener, de forma 
a tratar as mensagens recebidas em seu método onMessage. 
 
Um componente do tipo MDB nunca pode ser acessado diretamente, pois sua 
finalidade é a de tratar as mensagens recebidas a partir da mensageria. Para 
ativá-lo, o que se faz necessário é a postagem de uma mensagem na fila ou 
tópico assistido por esse componente. 
 
A arquitetura do JEE e a caracterização dos demais EJBs serão discutidas 
posteriormente nessa disciplina. 
 
 
(Figura representativa Java EE Server) 
 
 ARQUITETURA ORIENTADA A SERVIÇOS - SOA E WEBSERVICES 38 
 
Atividade proposta 
Como exercício de fixação,implemente um MDB que receba uma mensagem 
composta por dois números e um operador, e grave no log do servidor a conta 
efetuada e o resultado da mesma. 
 
Obs.: 
O formato da mensagem será <NUMERO>::<NUMERO>::<OPERADOR> 
 
Ex.: 
Para a mensagem 12.5::21.3::+ será gravado no log 12.5 + 21.3 = 33.8 
 
 
Referências 
Dahmann, J. Fujimoto, R. Weatherly, R. The Department of Defense High Level 
Architecture 
http://www.cc.gatech.edu/computing/pads/PAPERS/DOD_High_Lev
el_Arch.pdf 
 
Saudate, A. SOA aplicado: Integrando com web services e além, 
Editora Casa do Código, 2012. 
 
 
 
 
 
 
 
 
 
 
 
 
 ARQUITETURA ORIENTADA A SERVIÇOS - SOA E WEBSERVICES 39 
 
 
 
 
 
Exercícios de fixação 
Questão 1 
O que vem a ser RTI para a High Level Architecture? 
a) Uma aplicação com suporte a HLA e que pode participar de simulações neste 
ambiente. 
b) Uma simulação em execução. 
c) Apenas um temporizador para as diversas simulações. 
d) Uma máquina virtual para suportar aplicações Java. 
e) Basicamente um framework que garante uma infraestrutura de execução das 
simulações heterogêneas. 
 
Questão 2 
Quem foi a entidade responsável pela criação do HLA? 
a) Microsoft 
b) MEC 
c) Oracle 
d) FAB 
e) DMSO 
 
Questão 3 
Com a Gestão do tempo, o RTI: 
a) Controla o modelo de publicação e assinatura para troca de informações. 
b) Permite a transmissão eficiente de dados entre Federates. 
c) Coordena a linha de tempo de cada Federate dentro do eixo de tempo do 
Federation, garantindo a preservação de causa e ordenação. 
d) Controla todo o ciclo de vida e troca de mensagens entre os objetos. 
e) Controla as atividades de cada Federation durante a execução. 
 
 ARQUITETURA ORIENTADA A SERVIÇOS - SOA E WEBSERVICES 40 
 
Questão 4 
O que vem a ser Federate para a High Level Architecture? 
a) Uma aplicação com suporte a HLA e que pode participar de simulações neste 
ambiente. 
b) Uma simulação em execução. 
c) Apenas um temporizador para as diversas simulações. 
d) Uma máquina virtual para suportar aplicações Java. 
e) Basicamente um framework que garante uma infraestrutura de execução das 
simulações heterogêneas. 
 
Questão 5 
No ano de 2000 a High Level Architecture foi transformada em um padrão 
(standard). Qual foi a entidade normatizadora? 
a) DMSO 
b) DoD 
c) W3C 
d) SSL 
e) IEEE 
 
Questão 6 
Qual das opções abaixo NÃO é um exemplo de mensageria? 
a) JBoss MQ 
b) IBM MQ Series 
c) IPlanet MQ 
d) Bea Web Logic 
e) QueueSender 
 
Questão 7 
Onde é imprescindível um objeto ouvinte (MessageListener) para avisar que 
existe uma mensagem no canal da mensageria? 
a) Envio do modelo de fila 
 
 ARQUITETURA ORIENTADA A SERVIÇOS - SOA E WEBSERVICES 41 
b) Recepção do modelo de fila 
c) Envio do modelo de tópico 
d) Recepção do modelo de tópico 
e) Preparação prévia da mensagem para envio 
 
Questão 8 
Quando o uso de mensagerias NÃO é indicado? 
a) Quando o elemento principal da comunicação é o formato da mensagem 
b) Quando existe a necessidade de bloquear o cliente durante a transação 
c) Quando não é possível prever a disponibilidade dos componentes 
d) Quando é preciso suportar comunicação assíncrona 
e) Quando é necessário enviar a mensagem, mesmo que o receptor não esteja 
ativo 
 
Questão 9 
Podemos ter sistemas desenvolvidos em diferentes tecnologias, como Java e 
C#, cada uma com sua biblioteca de middleware para acesso à mensageria, 
nesse caso denominado: 
a) MOM 
b) RPC 
c) RMI 
d) JDBC 
e) EJB 
 
Questão 10 
Dentro do ambiente JEE, qual o nome do componente responsável por receber 
as mensagens advindas de uma mensageria? 
a) SessionBean 
b) Stateless 
c) MDB 
d) Stateful 
e) EntityBean 
 
 ARQUITETURA ORIENTADA A SERVIÇOS - SOA E WEBSERVICES 42 
 
 
 
 ARQUITETURA ORIENTADA A SERVIÇOS - SOA E WEBSERVICES 43 
Aula 2 
Exercícios de fixação 
Questão 1 - E 
Justificativa: A sigla RTI significa Infraestrutura de tempo de execução, e cuida 
do gerenciamento das Federates, Federation e Federation Execution, entre 
outros elementos. 
 
Questão 2 - E 
Justificativa: Quem criou o HLA foi o Defense Modeling and Simulation Office 
(DMSO). 
 
Questão 3 - C 
Justificativa: Os componentes responsáveis pelas funções citadas nestas opções 
são: 
 – Gestão de declarações, que controla o modelo de publicação e assinatura 
para troca de informações; 
 – Gestão de dados distribuídos, com a transmissão eficiente de dados 
entre Federates; 
 – Gestão de tempo, o qual coordena a linha de tempo de cada Federate 
dentro do eixo de tempo do Federation, garantindo a preservação de causa e 
ordenação. 
 – Gestão de objetos, controlando todo o ciclo de vida e troca de 
mensagens entre estes objetos; 
 – Gestão de Federation, que controla as atividades de cada Federation 
durante a execução. 
 
Questão 4 - A 
Justificativa: Uma aplicação compatível com o ambiente HLA é denominada 
Federate. 
 
 
 ARQUITETURA ORIENTADA A SERVIÇOS - SOA E WEBSERVICES 44 
Questão 5 - E 
Justificativa: Inicialmente a HLA foi normatizada pelo IEEE Standard 1516-2000. 
 
Questão 6 - E 
Justificativa: A única opção que não trata de uma mensageria comercial é o 
QueueSender. Este é, na verdade, o componente Java necessário para enviar 
uma mensagem no modelo de fila sem uso de EJBs. 
 
Questão 7 - D 
Justificativa: No modelo de tópico é necessário um objeto ouvinte 
(MessageListener) para avisar que há nova mensagem no canal, de forma que 
os assinantes possam recebê-la. 
 
Questão 8 - B 
Justificativa: O uso de mensagerias é indicado em todos estes casos, menos 
quando há necessidade de bloquear o cliente, isso porque o funcionamento é 
justamente o oposto, sem bloqueio do cliente, o que viabiliza o comportamento 
assíncrono. 
 
Questão 9 - A 
Justificativa: O middleware para acesso a mensagerias é denominado MOM, ou 
Message Oriented Middleware. As opções RPC e RMI referem-se a sistemas de 
processamento distribuído, enquanto JDBC é o middleware para acesso a banco 
de dados do Java, e o EJB um componente corporativo da plataforma JEE. 
 
Questão 10 - C 
Justificativa: O componente responsável pela recepção das mensagens é o 
Message Driven Bean, definido pela anotação @MessageDriven, e que precisa 
implementar a interface MessageListener. 
 
 
 
 ARQUITETURA ORIENTADA A SERVIÇOS - SOA E WEBSERVICES 45 
Introdução 
Uma evolução natural da programação foi a utilização de processamento 
paralelo para a resolução de problemas complexos. 
 
A distribuição de processamento também é utilizada com tal finalidade, ou em 
situações nas quais os participantes de uma transação não se encontram 
fisicamente no mesmo local. 
 
Esta aula visa elucidar conceitos como processamento paralelo e distribuído, 
além de descrever tecnologias de grande aceitação na implementação de 
sistemas distribuídos, como RPC e RMI. 
 
Objetivo: 
1. Compreender o processamento distribuído e uso do RPC; 
2. Conhecer a tecnologia Java RMI. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 ARQUITETURA ORIENTADA A SERVIÇOS - SOA E WEBSERVICES 46 
Conteúdo 
 
Processamento paralelo 
1945 
Já em 1945, nos trabalhos de Von Neumann, as arquiteturas de processamento 
paralelo eram apresentadas como uma solução para aumento do poder de 
processamento. 
 
As técnicas de processamento paralelo sempre visaram ao melhor 
aproveitamento do tempo de CPU, particularmente quando ocorriam 
“demorados” procedimentos de Entrada e Saída. 
 
1950 a 1970 
De 1950 a 1970 era comum a utilização de computadores monoprocessados. 
Havia uma busca por processadores cada vez mais velozes, porém existiam 
barreiras físicas para essa velocidade, assim, a solução mais viável para a 
otimização do tempo consistiria posteriormente em trabalhar com máquinas 
multiprocessadas. 
 
A miniaturização proporcionada pela evolução da tecnologia de transistores 
permitiu que até mesmo bilhõesdeles fossem integrados em um chip, 
viabilizando a definição de arquiteturas de processadores com mais unidades 
funcionais e memória cache. 
 
Com isso, temos hoje processadores com vários núcleos, com grande poder de 
processamento, mais bem explorados pelas técnicas de programação paralela 
com multitarefa. 
 
Em linguagem Java, uma tarefa independente pode ser definida pela extensão 
da classe Thread. Outra forma seria a implementação da interface Runnable, o 
que não elimina a necessidade da chamada inicial com uma classe Thread. A 
tarefa que deverá ser executada continuamente em paralelo é definida no 
 
 ARQUITETURA ORIENTADA A SERVIÇOS - SOA E WEBSERVICES 47 
método run, e quando há necessidade de sincronização utiliza-se a palavra-
chave synchronized. 
 
 
 
(imagem representativa do método run) 
 
 ARQUITETURA ORIENTADA A SERVIÇOS - SOA E WEBSERVICES 48 
Processamento distribuído 
A distribuição de processamento também pode ocorrer ao longo de uma rede, 
com diferentes processos sendo executados em máquinas remotas, segundo 
protocolos específicos de comunicação. 
 
O termo DCE (Distributed Computing Environment) é comumente utilizado para 
definir esse tipo de ambiente, onde vários componentes de software, como 
serviços de diretórios, gestores de segurança, sistemas de objetos distribuídos, 
entre vários outros, trabalham em conjunto para a construção de complexos 
sistemas corporativos. 
 
Dentro de uma rede TCP-IP, a definição de um serviço distribuído de forma 
mais simples envolve a construção de um servidor, normalmente trabalhando 
com paralelismo, que seja capaz de escutar uma porta específica destinada ao 
serviço oferecido, e clientes capazes de se comunicar com esse servidor 
segundo um protocolo previamente estabelecido. 
 
Um código em linguagem Java de exemplo para a criação de um sistema 
cliente-servidor com uso de Socket. 
 
Embora qualquer sistema cliente-servidor possa atuar dessa forma, algumas 
arquiteturas próprias foram definidas para a formalização dos serviços 
distribuídos, como o RPC e o RMI. 
 
 
 ARQUITETURA ORIENTADA A SERVIÇOS - SOA E WEBSERVICES 49 
 
 
 
 
 
 ARQUITETURA ORIENTADA A SERVIÇOS - SOA E WEBSERVICES 50 
 
(imagem representativa de um código em linguagem Java) 
 
RPC (Remote Procedure Call) 
A chamada remota de procedimento (RPC) trata de um modelo de comunicação 
entre processos que viabiliza a chamada de um procedimento em outro espaço 
de endereçamento, normalmente em outro computador da rede, sem que o 
programador tenha que se preocupar com detalhes dessa interação remota, 
assemelhando-se a chamadas locais em termos de código. 
 
Com isso, o uso de RPC simplifica a criação de sistemas distribuídos deixando a 
comunicação transparente para o programador. 
 
Essa é uma ideia antiga, datando de 1976, quando foi descrita na RFC 707. Foi 
utilizada de maneira comercial inicialmente pela Xerox, em 1981, sendo a 
primeira implementação popular efetuada para UNIX com o Sun RPC, usado 
como base para o NFS (Network File System). 
 
Várias extensões da comunicação remota para ambientes de objetos 
distribuídos, como CORBA e DCOM, são baseadas em diferentes 
implementações do RPC. As ferramentas para criação de aplicativos RPC 
cuidam da geração dos stubs para garantir essa transparência. 
 
 ARQUITETURA ORIENTADA A SERVIÇOS - SOA E WEBSERVICES 51 
A ideia fundamental é a de que o servidor exporta apenas a interface de 
procedimentos e funções, da mesma forma que ocorreria com uma API ou 
biblioteca. 
 
O programa cliente faz a chamada ao procedimento remoto, com a passagem 
dos parâmetros necessários, e recebe a resposta, como se estivesse chamando 
um simples método local. 
 
O par de stubs faz a transformação de chamadas e respostas nas mensagens 
necessárias para a comunicação em rede. Em termos do servidor, esse 
elemento responsável pela interceptação das chamadas é comumente 
denominado skeleton, e deve receber a chamada, ativar o componente de 
software responsável pelo processamento do pedido, e retornar com a resposta 
solicitada. 
 
Com todas essas características, o único vínculo real entre o código do cliente e 
o do servidor é a interface de exposição de serviços, a qual segue uma sintaxe 
bastante simples. 
 
Um exemplo de sistema com uso de RPC na sintaxe C, bem como a interface de 
exposição dos serviços: 
 
/* addsub.x : definição da interface */ 
#define PROGRAM_NUMBER 12345678 
#define VERSION_NUMBER 1 
 
/* tipo de dado que será passado aos procedimentos remotos */ 
 
struct operands 
{ 
 int x; 
 int y; 
 
 ARQUITETURA ORIENTADA A SERVIÇOS - SOA E WEBSERVICES 52 
}; 
 
/* Definição da interface que será oferecida aos clientes */ 
 
program ADDSUB_PROG 
{ 
 version ADDSUB_VERSION 
 { 
 int ADD (operands) = 1; 
 int SUB (operands) = 2; 
 } 
 = VERSION_NUMBER; 
} 
= PROGRAM_NUMBER; 
 
Com o uso do utilitário rpcgen são gerados vários arquivos a partir desse 
arquivo de interface, compreendendo toda a parte de comunicação e oferta de 
serviços, o que deixará para o programador a simples tarefa de implementar as 
regras de negócios do aplicativo, sem se desgastar com a comunicação e 
distribuição. 
 
/* Arquivo server.c: um servidor RPC simples */ 
#include <stdio.h> 
#include "addsub.h" 
 
/* implementação da função add */ 
int * add_1_svc (operands *argp, struct svc_req *rqstp) 
{ 
 static int result; 
 
 printf ("Recebi chamado: add %d %d\n", argp->x, argp->y); 
 result = argp->x + argp->y; 
 return (&result); 
} 
 
/* implementação da função sub */ 
 
 ARQUITETURA ORIENTADA A SERVIÇOS - SOA E WEBSERVICES 53 
int * sub_1_svc (operands *argp, struct svc_req *rqstp) 
{ 
 static int result; 
 
 printf ("Recebi chamado: sub %d %d\n", argp->x, argp->y); 
 result = argp->x - argp->y; 
 return (&result); 
} 
 
O código do cliente é um pouco mais complexo que o do servidor, mas é fácil 
observar como a chamada remota assemelha-se a uma simples chamada de 
função local. 
/* Arquivo client.c: um cliente RPC simples */ 
 
#include <stdio.h> 
#include "addsub.h" 
 
/* função que chama a RPC add_1 */ 
int add (CLIENT *clnt, int x, int y) 
{ 
 operands ops; 
 int *result; 
 
 /* junta os parâmetros em um struct */ 
 ops.x = x; 
 ops.y = y; 
 
 /* chama a função remota */ 
 result = add_1 (&ops,clnt); 
 if (result == NULL) 
 { 
 printf ("Problemas ao chamar a função remota\n"); 
 exit (1); 
 } 
 
 return (*result); 
} 
 
int main( int argc, char *argv[]) 
{ 
 CLIENT *clnt; 
 int x,y; 
 
 
 ARQUITETURA ORIENTADA A SERVIÇOS - SOA E WEBSERVICES 54 
 /* verifica se o cliente foi chamado corretamente */ 
 if (argc!=4) 
 { 
 fprintf (stderr,"Usage: %s hostname num1 num2\n",argv[0]); 
 exit (1); 
 } 
 
 /* cria uma struct CLIENT que referencia uma interface RPC */ 
 clnt = clnt_create (argv[1], ADDSUB_PROG, ADDSUB_VERSION, "udp"); 
 
 /* verifica se a referência foi criada */ 
 if (clnt == (CLIENT *) NULL) 
 { 
 clnt_pcreateerror (argv[1]); 
 exit(1); 
 } 
 
 /* obtém os dois inteiros que serão passados via RPC */ 
 x = atoi (argv[2]); 
 y = atoi (argv[3]); 
 
 /* executa um procedimento remoto */ 
 printf ("%d + %d = %d\n", x, y, add (clnt,x,y)); 
 
 return (0); 
} 
(imagens representativas de Interface para definição dos serviços (IDL).) 
 
RM(Remote Method Invocation) 
A tecnologia RMI pode ser considerada como a versão orientada a objetos do 
RPC, disponível para a linguagem Java. 
 
Nesse modelo o que temos é um objeto hospedado e executado em 
determinado servidor, registrado via RMI Registry, e que disponibiliza métodos 
para acesso remoto. 
 
A arquitetura de comunicação do RMI pode ser observada no desenho seguinte, 
onde pode ser vista a presençados stubs nos clientes e do skeleton no 
servidor. 
 
 ARQUITETURA ORIENTADA A SERVIÇOS - SOA E WEBSERVICES 55 
 
 
(imagem representativa da tecnologia RMI) 
 
O passo inicial para o desenvolvimento de um sistema com uso de RMI é a 
definição da interface remota, o que equivaleria à definição da IDL utilizada no 
RPC, porém restrita ao universo Java. 
 
 
Essa interface deverá ser descendente da interface Remote e cada método dela 
deverá considerar a ocorrência da exceção RemoteException, como pode ser 
observado no exemplo seguinte: 
 
 
 ARQUITETURA ORIENTADA A SERVIÇOS - SOA E WEBSERVICES 56 
 
 
Criada a interface, deve ser definido um objeto servidor que a implementa, 
criando assim os métodos do serviço. 
 
Esse objeto também deve ser descendente de UnicastRemoteObject. 
 
Um objeto da classe CalcRemote deve ser instanciado e registrado pelo 
programa servidor, ficando disponível para os clientes através da escuta 
efetuada pelo RMI Registry. 
 
 
 
 
 ARQUITETURA ORIENTADA A SERVIÇOS - SOA E WEBSERVICES 57 
 
 
Com relação ao cliente, este deverá localizar o objeto servidor através do 
protocolo gerenciado pelo RMI Registry, efetuando a chamada aos métodos 
remotos, segundo o que foi definido em ICalcRemote. 
 
O uso de RMI permite a definição de um DCE de grande simplicidade de uso 
para a linguagem Java, permitindo a passagem de informações através de 
objetos serializáveis mais complexos, segundo um padrão Proxy, diminuindo 
muito o esforço de programação. 
 
No entanto, quando são tratados os sistemas corporativos, vários requisitos, 
como transações, pooling e autenticação, podem não ser oferecidos de forma 
simples pelo RMI. Para satisfazer a esse tipo de necessidade são utilizados 
ambientes de objetos distribuídos. 
 
Marshalling e Unmarshalling 
Um conceito comum em termos de programação orientada a objetos é a 
serialização de objetos. 
 
A serialização é a transformação de dados em geral, que estejam em memória, 
para um formato adequado em array de bytes, pronto para armazenagem ou 
transferência do mesmo. 
 
 
 ARQUITETURA ORIENTADA A SERVIÇOS - SOA E WEBSERVICES 58 
Em outro momento o processo inverso (desserialização) pode ser efetuado, 
partindo do array de bytes e montando a estrutura novamente em memória, 
claro que ocupando locais diferentes da mesma. 
 
Em termos de comunicação remota, um conceito similar é o de Marshalling e 
Unmarshalling, pois trata da transformação dos dados estruturados segundo 
uma determinada tecnologia, como Java ou C#, em formato compatível com as 
mensagens que são trafegadas entre os stubs (Marshalling), bem como o 
processo inverso, para a recuperação dos dados a partir da mensagem 
(Unmarshalling), lembrando que nas duas pontas as linguagens podem ser 
distintas. 
 
Serviços de nomes e diretórios 
A chamada remota de procedimento (RPC) trata de um modelo de comunicação 
entre processos que viabiliza a chamada de um procedimento em outro espaço 
de endereçamento, normalmente em outro computador da rede, sem que o 
programador tenha que se preocupar com detalhes dessa interação remota, 
assemelhando-se a chamadas locais em termos de código. 
 
 Associam nomes a recursos computacionais em rede; 
 
 Funcionam como “diretórios” compartilhados; 
 
 Envolvem funções de localização e registro de elementos; 
 
 Permitem armazenar objetos, certificados digitais e outros elementos 
serializáveis. 
 
Amplamente utilizados pelas instituições bancárias, DAP (Directory Access 
Protocol) e LDAP (Lightweight Directory Access Protocol) são exemplos desse 
tipo de serviço. No caso da tecnologia Java, as ações de registro e localização 
são feitas pelo JNDI (Java Naming and Directory Interface), o qual apresenta 
 
 ARQUITETURA ORIENTADA A SERVIÇOS - SOA E WEBSERVICES 59 
uma interface única entre os diversos serviços de diretório, gerenciando 
inclusive o acesso a recursos como RMI, CORBA, DAP, LDAP e JEE. 
 
Atividade proposta 
Implemente um serviço RMI que receba o valor de dois catetos de um triângulo 
retângulo e retorne o valor da hipotenusa. 
Parâmetros de entrada: double cateto1, double cateto2 
Retorno: double 
Cálculo: hipotenusa = Math.sqrt(Math.pow(cateto1,2)+Math.pow(cateto2,2)) 
 
Referências 
Silva, F. Sistemas Distribuídos: Conceitos e Projeto RPC e RMI, UFMA, 2013 
http://www.deinf.ufma.br/~fssilva/graduacao/sd/aulas/rpc_rmi.pdf 
 
Grosso, W. Java RMI (Java Series), O’Reilly, 2001. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 ARQUITETURA ORIENTADA A SERVIÇOS - SOA E WEBSERVICES 60 
Exercícios de fixação 
Questão 1 
Quando trabalhamos com processamento paralelo, um problema comum é a 
utilização de recursos compartilhados que podem ser lidos ou escritos de forma 
errônea devido à preempção. Para resolver isso deve ocorrer um 
sequenciamento no acesso ao recurso, o que é obtido no Java com o uso da 
palavra reservada: 
a) static 
b) volatile 
c) synchronized 
d) abstract 
e) final 
 
Questão 2 
Uma classe ServerSocket deve escutar uma porta especificada e aceitar 
conexões solicitadas pelos clientes, repassando as mesmas para objetos Socket 
locais, o que define o circuito virtual entre cliente e servidor. Qual o método 
utilizado para aceitar uma conexão? 
a) start 
b) accept 
c) getInputStream 
d) getOutputStream 
e) close 
 
Questão 3 
A utilização de RPC viabiliza a construção de sistemas de processamento 
distribuído com um formato de comunicação transparente para o programador. 
Quem permite esta transparência são os _______________ definidos para o 
padrão Proxy. 
a) senders 
b) idles 
c) clients 
 
 ARQUITETURA ORIENTADA A SERVIÇOS - SOA E WEBSERVICES 61 
d) stubs 
e) publishers 
 
Questão 4 
Na arquitetura do RPC, o elemento responsável por tratar as chamadas no 
servidor é denominado: 
a) IDL 
b) stub 
c) skeleton 
d) Socket 
e) ServerSocket 
 
Questão 5 
O elemento na arquitetura do RPC que permite a geração automática de todo o 
aparato de comunicação em rede, de forma automatizada, por ferramentas 
como o rpcgen é: 
a) IDL 
b) stub 
c) skeleton 
d) Socket 
e) ServerSocket 
 
Questão 6 
Em sistemas de processamento distribuído ocorre a necessidade de registrar e 
localizar componentes disponibilizados remotamente. O componente de 
software responsável por executar esta função seria: 
a) Interface de Descrição de Serviços 
b) Serviço de Nomes e Diretórios 
c) Temporizador 
d) Protocolo de Comunicação 
e) Gerenciador do Banco de Dados 
 
 
 ARQUITETURA ORIENTADA A SERVIÇOS - SOA E WEBSERVICES 62 
Questão 7 
A transformação dos dados estruturados segundo uma determinada tecnologia, 
como Java ou C#, em formato compatível com as mensagens que são 
trafegadas entre os stubs é denominada: 
a) serialização 
b) unmarshalling 
c) marshalling 
d) de-serialização 
e) vetorização 
 
Questão 8 
Em termos de RMI a descrição dos serviços é feita na própria linguagem Java 
através de uma interface descendente de: 
a) Remote 
b) Runnable 
c) MessageListener 
d) Serializable 
e) CommandListener 
 
Questão 9 
Considere as afirmativas abaixo: 
I – Os métodos expostos pela interface remota do RMI devem considerar a 
ocorrência da exceção RemoteException. 
II – Criada a interface, deve ser definido uma classe que implementa a mesma 
e seja descendente de UnicastRemoteObject. 
III – Os passos I e II são necessários e suficientes para a criação de um 
servidor RMI. 
Quais as afirmativas corretas? 
a) Todas estão corretas 
b) Apenas a I está correta 
c) Apenas a II está correta 
d) As alternativas I e II estão corretas 
 
 ARQUITETURA ORIENTADA A SERVIÇOS - SOA E WEBSERVICES 63 
e) Nenhuma está correta 
 
Questão 10 
No ambiente Java os serviços de nomes e diretórios são acessados através de: 
a) DAP 
b) LDAP 
c) DNS 
d) JEE 
e) JNDI 
 
 
 
 ARQUITETURA ORIENTADA A SERVIÇOS - SOA E WEBSERVICES 64 
Aula