14785589987745587

Apresentao ............................................................................................................................
5
Aula 1: Interoperabilidade - Necessidades e Conceitos ................................................ 6
Introduo ............................................................................................................................. 6
Contedo................................................................................................................................ 7
Histrico da integrao de sistemas .............................................................................. 7
Fatores considerados na escolha de COTS .................................................................. 8
Integrao via banco de dados ....................................................................................... 9
Integrao via protocolo ................................................................................................ 11
Interoperabilidade ........................................................................................................... 13
Padronizao de interfaces ........................................................................................... 14
Independncia de fornecedores ................................................................................... 16
Atividade proposta .......................................................................................................... 18
Referncias........................................................................................................................... 18
Exerccios de fixao ......................................................................................................... 19
Chaves de resposta ..................................................................................................................... 23
Aula 2: Arquitetura Voltadas para Interoperabilidade ................................................ 25
Introduo ........................................................................................................................... 25
Contedo.............................................................................................................................. 26
High level architecture .................................................................................................... 26
HLA e RTI........................................................................................................................... 27
Mensagerias ...................................................................................................................... 32
Fila....................................................................................................................................... 33
Tpicos .............................................................................................................................. 34
Utilizao de mensagerias ............................................................................................. 35
Message driven bean ....................................................................................................... 36
Referncias........................................................................................................................... 38
Aula 3: Processamento Distribudo com RPC e RMI ..................................................... 45
Introduo ........................................................................................................................... 45
Contedo.............................................................................................................................. 46
Processamento paralelo ................................................................................................. 46
ARQUITETURA ORIENTADA A SERVIOS - SOA E WEBSERVICES 1

Processamento distribudo ............................................................................................ 48
RPC (Remote Procedure Call)......................................................................................... 50
RM(Remote Method Invocation).................................................................................... 54
Marshalling e Unmarshalling .......................................................................................... 57
Servios de nomes e diretrios ..................................................................................... 58
Referncias........................................................................................................................... 59
Aula 4: Objetos Distribudo com CORBA e JEE .............................................................. 66
Introduo ........................................................................................................................... 66
Contedo.............................................................................................................................. 67
Objetos distribudos ........................................................................................................ 67
CORBA ............................................................................................................................... 69
RMI-IIOP ............................................................................................................................ 71
Java Enterprise Edition .................................................................................................... 74
Chamada de JEE por ferramentas CORBA ................................................................. 78
Referncias........................................................................................................................... 83
Aula 5: Tecnologias Voltadas para XML .......................................................................... 91
Introduo ........................................................................................................................... 91
Contedo.............................................................................................................................. 92
Sintaxe XML ....................................................................................................................... 92
Documento XML .............................................................................................................. 94
Entidades ........................................................................................................................... 96
Exemplo da W3C .............................................................................................................. 97
Formas gramaticais em XML ......................................................................................... 99
Linguagens de transformao .................................................................................... 100
XSLT .................................................................................................................................. 101
XSL-FO ............................................................................................................................. 103
Outras tecnologias XML................................................................................................ 106
Atividade proposta ........................................................................................................ 106
Referncias......................................................................................................................... 107
Exerccios de fixao ....................................................................................................... 108

Chaves de resposta ................................................................................................................... 111
Aula 6: Interoperabilidade com XML - RPC e Web Services ..................................... 114
Introduo ......................................................................................................................... 114
Contedo............................................................................................................................ 115
XML-RPC .......................................................................................................................... 115
Implementao em Java.............................................................................................. 118
SOAP................................................................................................................................. 119
Web Services................................................................................................................... 122
SOAP Web Services ........................................................................................................ 122
UDDI ................................................................................................................................. 124
Criao de SOAP Web Services em Java .................................................................. 125
Criao de Cliente dotNet ........................................................................................... 126
Sistemas B2B e B2C ....................................................................................................... 127
Referncias......................................................................................................................... 129
Aula 7: Arq. Orientadas a Servios - Conceitos e Definies ................................... 137
Introduo ......................................................................................................................... 137
Contedo............................................................................................................................ 138
Princpios do SOA .......................................................................................................... 138
Conceitos de arquitetura orientada a servio .......................................................... 140
Governana e Segurana ............................................................................................. 141
Telas sobre governana ............................................................................................... 142
Aspectos de segurana ................................................................................................. 143
Integrao e uso de tecnologias legadas.................................................................. 145
Uso de SOA ..................................................................................................................... 146
Uso de Web Services...................................................................................................... 149
Referncias......................................................................................................................... 151
Aula 8: Arq. Orientadas a Servios - ESB, BPMN e BPEL ............................................ 159
Introduo ......................................................................................................................... 159
Contedo............................................................................................................................ 159
ESB e middleware ........................................................................................................... 159

Metodologia de comunicao .................................................................................... 161
Adoo de um ESB ........................................................................................................ 162
Aplicao do ESB ........................................................................................................... 163
Orquestrao de servios............................................................................................. 166
BPMN................................................................................................................................ 167
Evento .............................................................................................................................. 167
Atividade .......................................................................................................................... 168
Gateway ........................................................................................................................... 169
Pool e Lane ...................................................................................................................... 169
BPEL .................................................................................................................................. 171
Referncias......................................................................................................................... 177
Conteudista ........................................................................................................................... 185

Conceito de arquitetura da informao. Metodologia de arquitetura da
informao para websites. Organizao do contedo, Sistema de navegao,
Sistema de rotulagem e busca. Estudo de usurios e do ambiente. Testes de
usabilidade. Modelagem. Conceituao e viso macroscpica de sites.
Representao: sitegrama, wireframes, etc. Implentao de sites.
Sendo assim, essa disciplina tem como objetivos:

1. Compreender a importncia e organizao do fluxo de informao visando
torn-la til atravs de planejamento e mapeamento visual e contextual,
assegurando a facilidade de utilizao em um sistema de aplicao local ou
web.
2. Conhecer um pouco da histria da informao na vida das pessoas e das
organizaes.
3. Compreender as semelhanas e diferenas entre a arquitetura convencional
e na construo de sistemas computacionais.
4. Conhecer conceito e atributos de usabilidade.
5. Compreender a importncia da arquitetura da informao, o conhecimento
de seus componentes e o esquema de organizao na criao de websites. .
6. Conhecer a importncia de design estrutural de ambientes de informao
compartilhados.

Introduo
A necessidade de integrao entre plataformas heterogneas sempre foi uma
necessidade nas reas tecnolgicas; e, no decorrer de vrias dcadas, mtodos
cada vez mais especializados em termos de hardware e software foram
evoluindo para que tal necessidade fosse suprida, permitindo o aumento do
reuso, diminuio de custos e melhoria das possibilidades de manuteno
devido obsolescncia.
Esta aula visa demonstrar os elementos histricos que trouxeram essa

necessidade tona e quais metodologias bsicas foram implementadas para
esse tipo de integrao, culminando com o atual conceito de interoperabilidade.
Objetivo:
1. Entender as metodologias primrias de integrao e problemas relacionados
a elas;
2. Compreender o conceito de interoperabilidade e tcnicas atuais para a sua
obteno.

Contedo
Histrico da integrao de sistemas

Com a expanso dos elementos tecnolgicos no decorrer da histria,
comearam a aparecer grandes conjuntos de dados independentes, os quais
no se comunicavam, gerando uma grande redundncia de informaes e
desperdcio de poder de processamento.
Muitos projetos apresentavam caractersticas semelhantes, mas, como no

existiam interfaces comuns, ocorria um grande retrabalho na construo de
novos produtos e bases de dados.
Em meados da dcada de 90, com a expanso dos sistemas, comearam a ser

oferecidas diferentes formas padronizadas de armazenar, recuperar e processar
dados de origem externa aos aplicativos. Atravs 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 no uma preocupao nova. Na rea de engenharia, sempre ocorreram

problemas quanto obsolescncia e preocupaes com manutenes. No
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 produo de um novo sistema de engenharia so

utilizados elementos funcionais prontos para uso, denominados COTS
(commercial off-the-shelf), os quais tratam de componentes comerciais
reutilizveis, testados e aceitos pelo mercado e integrveis com relativa
facilidade para a construo de produtos maiores.

Mesmo que um COTS apresente meios de integrao padronizados, essa
integrao acrescenta alguma complexidade ao sistema, pois o grande desafio
no uso de COTS adequar sua utilizao s necessidades do sistema sem
alterar o componente em si.
Esses componentes, ao apresentarem interfaces padronizadas, podem ser

substitudos 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 bsica por trs da interoperabilidade, a qual pode
ser definida como a capacidade de elementos heterogneos se comunicarem,
compartilhando dados e complementando funcionalidades.
Na rea da informtica, as atuais arquiteturas de software divididas em

camadas, como a MVC (model, view e control), viabilizaram a criao 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
especificaes para diversas reas, como criptografia, EJB (Enterprise Java
Beans), e muitos outros, nos quais diferentes fornecedores de componentes
devem seguir essas especificaes de forma a permitir uma fcil permutao
entre ambientes distintos. Acompanhe:
Quanto longevidade do componente, existem preocupaes acerca da

reposio e atualizao devido obsolescncia, devendo-se levar em conta a
existncia de similares e o custo ou esforo efetivo para a substituio do
componente no decorrer do ciclo de vida do sistema.
Alm desses, outros fatores considerados na escolha de COTS, tanto software

como hardware, so a confiabilidade, manutenibilidade, eficincia e eficcia.

Ainda com relao longevidade, comum, nas arquiteturas orientadas a
servio da atualidade, existirem meios de comunicao com tecnologias
legadas, como sistemas CORBA, diminuindo o custo de implementao de
novas funcionalidades ao reutilizar os servios j existentes em conjunto com
servios criados atravs de novas tecnologias para a complementao de
tarefas mais complexas.
Ainda nesta disciplina, observaremos as diversas formas de interoperabilidade

utilizadas de forma comercial, culminando na definio e uso de arquiteturas
orientadas a servio.
Integrao via banco de dados

O primeiro nvel de integrao obtido na informtica foi com o
compartilhamento de informaes em bancos de dados comerciais,
particularmente os bancos relacionais, como Oracle, Informix, DB2, SQL Server,
entre muitos outros.
As ferramentas de programao antigas tinham bibliotecas de acesso para

bancos de dados especficos, o que aumentava muito a dependncia do cdigo-
fonte em relao ao fornecedor do banco de dados. Posteriormente, a camada
de comunicao 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 dependncia da ferramenta em relao ao banco em termos de

programao, quando eram utilizados componentes especficos de acesso ao
invs de um middleware, acaba causando grande dependncia do cdigo e alto
acoplamento, o que acaba restringindo o uso de um determinado fornecedor de
banco ou ao menos dificultando a sua substituio, 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

apresentam ferramentas de desenvolvimento, como o Java, C# e Delphi.
Intermediando os dois lados, cada front-end adota uma plataforma de
middleware de dados prpria, como JDBC (Java Database Conectivity), ODBC
(Open Database Conecivity) ou BDE (Borland Database Engine), todas essas
voltadas para a intermediao entre o front-end e os diversos back-ends de
diferentes fornecedores.
Com essa modificao na concepo dos sistemas, hoje possvel 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-se
irrelevante em termos de cdigo.
Vantagens que essa abordagem inclui:
Infelizmente, nem tudo positivo, e alguns pontos negativos devem ser

considerados. So eles:
O uso de SQL proprietrio, como PL-SQL, pode diminuir a portabilidade do

banco.
Sem o tratamento adequado por todos os front-ends, os dados podero
apresentar inconsistncias.
Os mtodos transacionais no nvel do aplicativo podem sofrer o impacto dos
demais sistemas que compartilham o banco.

Qualquer alterao nos metadados ir trazer consequncias para os diversos
front-ends.
Se um sistema altera o formato de gravao de um campo, como de real para
monetrio, os outros sistemas podem parar de funcionar, dependendo do
banco de dados utilizado.
Ateno
Apesar dos problemas apresentados, o uso de middleware

facilitou muito o acesso a bancos de dados e viabilizou um
primeiro nvel de integrao entre sistemas, sendo esse ao nvel
dos dados.
O termo middleware no se restringe ao uso de banco de dados,

podendo tratar da conexo com mensagerias, sistemas de
arquivos e outros. Ele ser frequentemente utilizado nesta
disciplina, sendo melhor detalhado posteriormente.
Integrao via protocolo

Com o uso extensivo de redes na atualidade, fcil perceber que o uso de
protocolos de comunicao para viabilizar integrao entre sistemas uma
realidade, inclusive levando a conceitos como conectividade na definio das
caractersticas de sistemas operacionais mveis, entre outros.
Em termos gerais, o protocolo a formalizao da comunicao e transferncia

de dados entre dois sistemas computacionais. Ele define formato de chamada e
reposta, bem como comandos, tipos de dados aceitos e informaes
complementares.

Definido o protocolo, no importa quais tecnologias sero utilizadas para
implementar ambos os lados da comunicao, como Java e Dot Net, desde que
ambas sejam capazes de acessar a rede e trocar informaes 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 mveis via
Bluetooth, ou que esse mesmo dispositivo acesse um servidor HTTP hospedado
em ambiente de nuvem.
Outro exemplo so 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 so as redes TCP-IP, o uso de Sockets, onde

associado o endereo IP a uma porta que caracteriza a aplicao, tornou-se
comum na criao de sistemas remotos; e, com isso, foram definidos servios
genricos de transferncia de dados.

Ateno
Com protocolos de comunicao bem definidos, duas

plataformas distintas podem trabalhar em conjunto, resumindo o
acoplamento dos aplicativos simples aceitao do protocolo
formal.
Interoperabilidade
Os sistemas, em geral, tm evoludo muito, e vrias solues 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 interopervel deve permitir acesso a suas funcionalidades segundo

padres de comunicao abertos, aceitos pelo mercado, de forma a tornar
transparente, ou quase, o processo de integrao.
Embora seja antigo o interesse da engenharia de sistemas pelo tema,

inicialmente a integrao ocorria apenas no nvel dos dados, com a definio de
formatos e meios de armazenamentos comuns; mas os sistemas foram se
tornando mais complexos, novos padres de comunicao com o meio externo
foram definidos, e a interoperabilidade evoluiu para o nvel de processos e
servios.
O interesse de empresas e rgos governamentais pelo tema pode ser

observado pelo grande nmero de normas existentes com o objetivo de trazer
padronizao aos elementos envolvidos nas mais diversas fases do ciclo de vida
dos sistemas.

Um pequeno exemplo de interoperabilidade foi a disponibilizao 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 dcadas.
Com a disponibilizao 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 necessrios para uma mala direta.
Mas a interoperabilidade vai muito alm disso, e o elemento principal para

viabiliz-la seria a definio de padres de interface abertos que permitissem a
exposio e uso de ferramentas com o mnimo de acoplamento possvel.
Ateno
Quando uma metodologia ou ferramental tecnolgico promete

diminuir o acoplamento, isso significa dizer que os componentes
e protocolos viabilizam uma independncia bem maior por parte
de cada participante nas diversas transaes.
Padronizao de interfaces
A busca de interfaces com baixo acoplamento para acesso a servios e
componentes passou por grandes evolues no decorrer do tempo. Um
exemplo de interface padronizada visando interoperabilidade em termos de
software a evoluo da tecnologia OLE, j citada anteriormente,
posteriormente servindo de base para componentes Active X e COM
(Component Object Model).
As plataformas que viabilizavam a criao desses tipos de componentes

precisam se preocupar apenas em atender interface de programao

formalmente definida pela Microsoft, a qual trabalha necessariamente com as
interfaces IUnknow e IDispatch.
Com o uso dessa interface-padro de programao e ativao de objetos

Microsoft, ferramentas como Delphi e Visual Basic passaram a criar objetos
intercambiveis dentro do ambiente Windows.
Em termos de redes, inicialmente as interfaces eram baseadas na simples

aceitao de protocolos formais, mas posteriormente servios de rede se
especializaram, levando adoo de padres para a execuo remota de
procedimentos.
Exemplos de padronizao e especializao de interfaces para execuo em
redes seriam o RPC (Remote Procedure Call) e o RMI (Remote Method
Invocation), preocupados com a padronizao da chamada a procedimentos e
mtodos de forma remota.
Paralelamente, surgiram sistemas de mensageria que permitiam trabalhar de

forma assncrona, com uso de tecnologias distintas, pelas quais o acoplamento
se restringe ao canal de comunicao entre os aplicativos.
Os ambientes de objetos distribudos comearam a ser utilizados, com a

padronizao dos protocolos de acesso e regras para escrita das interfaces,
sem foco em linguagens especficas, 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 construo de plataformas de objetos distribudos, a complexidade para a
construo desse tipo de ambiente fez com que apenas alguns se destacassem.
Alguns exemplos de plataformas de objetos distribudos 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

oferecer modelos padronizadas para definir a localizao dos componentes e
exposio da interface de servios de cada um.
Tomando como exemplo a questo do servio de localizao e registro de

componentes, o CORBA utiliza COS Naming, enquanto o JEE trabalha com JNDI
(Java Naming and Directory Interface). Nesse segundo, utilizada tambm a
interface padro do Java para servios de nomes, a qual unifica os mtodos de
nomeao de componentes, desde um EJB (Enterprise Java Bean) at um pool
de conexes 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 aceitao no mercado.
Por fim, o mercado passa adotar arquiteturas orientadas a servios, por meio
das quais um grande conjunto de ferramentas, como middlewares,
orquestradores de servio, disponibilizao de web services, acesso a
tecnologias legadas, entre muitos outros elementos, garantem o melhor nvel
de reuso e interoperabilidade dentro de um ambiente corporativo.
Alm dos exemplos comercialmente conhecidos e que apresentam reas fins

bastante genricas, em muitos nichos especficos tais interfaces foram
definidas, como o protocolo HL7 (Health Level 7 ), protocolo internacionalmente
aceito na rea de sade, e a High Level Architecture, na rea de simulaes
militares.
Independncia 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 fcil obter um meio de armazenamento compatvel

com vrios computadores, ao contrrio do que ocorria nos primeiros

computadores pessoais, quando era comum os fabricantes trabalharem com
interfaces distintas, at mesmo para evitar a suposta concorrncia.
Tambm na rea de software essa independncia de fornecedores foi bastante

almejada, pois, com as possibilidades de integrao e definio de interfaces
padronizadas, mais fornecedores se animaram com a possibilidade de atingir
nichos especficos, reutilizveis em vrios sistemas, como nos casos de bancos
de dados e mensagerias.
A definio de arquiteturas e metodologias independentes de plataforma ou

fornecedores especficos viabiliza a concorrncia direta, causando um efeito no
mercado de aumento de qualidade e diminuio do custo, estimulando tambm
a melhoria dos meios de produo nas reas relacionadas a hardware.
Um exemplo utilizado para promover essa independncia, j citado

anteriormente, o uso de middleware, pois, com a adoo de uma camada
intermediria 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 crticos direcionar a escolha
para um grupo menor de fornecedores.
As mensagerias com formato padronizado de mensagem tambm permitem a

substituio de seu fornecedor, fazendo com que aspectos de segurana e
robustez passem a ser analisados frente ao custo da implantao de uma
mensageria especfica.
Vrias solues de cdigo aberto tambm passaram a ser utilizadas, o que foi
observado muito facilmente na rea de banco de dados com a adoo de
MySQL por diversas empresas.
Em termos de servidores, a padronizao dos componentes JEE, bem como

CORBA, permite que seja escolhido um entre vrios servidores com

caractersticas 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.
Ateno
A cada vez que uma nova possibilidade de integrao surge,

novas possibilidades de desenvolvimento se abrem, novos
fornecedores surgem, e acabam aparecendo tambm produtos e
metodologias para aumentar as funcionalidades da prpria
plataforma de integrao.
Atividade proposta
Como atividade de fixao, efetue uma pesquisa acerca de metodologias
abertas de integrao entre sistemas e tecnologias que visam a
interoperabilidade.
Referncias
Cople, D. Um framework para Anlise 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

Exerccios de fixao
Questo 1
Uma prtica que se tornou comum na rea de engenharia foi a adoo de
COTS. Qual das caractersticas abaixo NO pode ser considerada como
referente a um componente deste tipo?
a) Apresentam meios de integrao padronizados.
b) So componentes comerciais reutilizveis.
c) Baseiam-se em padres abertos de interface.
d) Visam proteger tecnologias proprietrias.
e) Facilitam a manuteno do sistema, apesar de acrescentarem alguma
complexidade em termos de integrao.
Questo 2
Qual conceito pode ser definido como "a capacidade de elementos
heterogneos se comunicarem, compartilhando dados e complementando
funcionalidades "?
a) Middleware
b) Interoperabilidade
c) Front-End
d) Back-End
e) COTS
Questo 3
Um protocolo de rede pode ser considerado como um elemento bastante
primrio 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 aplicao.
b) O protocolo UDP atua na camada de transporte.

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 aplicao.
Questo 4
Considere as afirmativas abaixo acerca de middleware:
I Permite transparncia com relao ao fabricante do banco de dados.
II O uso de SQL proprietrio no diminui a portabilidade com relao ao tipo
de banco de dados.
III Faz a mediao entre Front-End e Back-End.
IV Permite acessar bancos de dados legados de tecnologias legadas a partir
de novas ferramentas de desenvolvimento.
Quantas opes esto corretas?
a) Nenhuma
b) 1
c) 2
d) 3
e) 4
Questo 5
Existem preocupaes acerca da reposio e atualizao devido a
obsolescncia, devendo ser levado em conta a existncia de similares e o custo
ou esforo efetivo para a substituio do mesmo no decorrer do ciclo de vida do
sistema. Para satisfazer a este tipo de preocupao, qual fator deve ser
considerado na escolha de COTS?
a) Eficincia
b) Eficcia
c) Longevidade
d) Confiabilidade
e) Manutenibilidade
Questo 6

Entre os elementos abaixo, qual deles NO um exemplo de interface
padronizada entre linguagens de programao?
a) COM
b) ActiveX
c) RPC
d) RMI
e) BDE
Questo 7
Sobre as tecnologias OLE e DDE, o que podemos afirmar?
a) Voltadas para a integrao entre o Delphi e o banco de dados.
b) Tecnologias que funcionam independente do sistema operacional.
c) Permitem a incorporao de uma planilha em um documento texto no pacote
Microsoft Office.
d) Foram ambas criadas pela Oracle.
e) So a base do protocolo SOAP.
Questo 8
Considerando-se o CORBA, os EJBs e o DCOM, estes so exemplos de que tipo
de tecnologia?
a) Gramticas XML
b) Objetos Distribudos
c) Sistemas Operacionais
d) Tecnologias Proprietrias
e) Componentes de Hardware
Questo 9
Qual tecnologia permite um comportamento assncrono, com acoplamento
muito fraco, baseado apenas nas mensagens enviadas pelo canal de
comunicao?
a) Mensageria
b) RPC

c) RMI
d) CORBA
e) Banco de dados
Questo 10
Qual a sintaxe que trouxe uma vertiginosa evoluo dos modelos de
interoperabilidade, sendo de grande utilizao nas arquiteturas orientadas a
servio da atualidade?
a) Java
b) HTML
c) XML
d) Delphi
e) C++

Aula 1
Exerccios de fixao
Questo 1 - D
Justificativa: Estes componentes, ao apresentarem interfaces padronizadas,
podem ser substitudos por outros equivalentes, independente de fornecedor.
Questo 2 - B
Justificativa: A ideia bsica por trs da interoperabilidade pode ser definida
como a capacidade de elementos heterogneos se comunicarem,
compartilhando dados e complementando funcionalidades. Quanto ao
Middleware e COTS, estes viabilizam a interoperabilidade em determinados
contextos restritos.
Questo 3 - C
Justificativa: Esta uma confuso comum em diversos blogs e discusses
acerca de redes. Em verdade so dois protocolos: o TCP atuando na camada de
transporte, e o IP atuando na camada de rede. No existe o protocolo TCP/IP.
Questo 4 - D
Justificativa: A opo II est incorreta, pois para manter a portabilidade de
banco de dados deve ser utilizado apenas o SQL ANSI. As demais opes esto
corretas.
Questo 5 - C
Justificativa: O fator que satisfaz necessidade apresentada a longevidade,
pois eficincia e eficcia referem-se s caractersticas funcionais prprias do
sistema, e confiabilidade e manutenibilidade referem-se a caractersticas de
manuteno pontuais dos COTS, sem uma viso de atualizao e reposio no
decorrer do tempo.

Questo 6 - E
Justificativa: Enquanto as demais opes permitem o uso de linguagens de
programao distintas na implementao dos componentes, o BDE trata de um
middleware exclusivo do Delphi para acesso a banco de dados.
Questo 7 - C
Justificativa: Quem voltado exclusivamente para integrao entre Delphi e
banco de dados o BDE. Quanto ao OLE e DDE, estas so tecnologias da
Microsoft, que executam em ambiente Windows, e so muito utilizadas na
integrao entre os softwares do pacote Microsoft Office. Quanto ao protocolo
SOAP, ele baseado em sintaxe XML.
Questo 8 - B
Justificativa: Os trs so exemplos de objetos distribudos (software), sendo
que o CORBA no tecnologia proprietria. Nenhum dos exemplos define uma
gramtica XML e, por fim, no so sistemas operacionais, como seria o caso do
Windows e do Linux.
Questo 9 - A
Justificativa: O conceito exposto a prpria definio de sistemas de
mensageria, alm de ser a nica das cinco tecnologias citadas que viabiliza
nativamente o comportamento assncrono.
Questo 10 - C
Justificativa: As arquiteturas orientadas a servio da atualidade trabalham muito
com a sintaxe XML, particularmente com o uso do mesmo atravs do protocolo
SOAP. Como caractersticas fortes da sintaxe podemos ressaltar a facilidade de
manuseio por qualquer linguagem e a transparncia na transmisso atravs de
firewalls.

Introduo
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 princpio.
Essa aula ir apresentar uma arquitetura baseada em interoperabilidade

utilizada na rea de simulaes militares, a qual denominada HLA (high level
architecture), bem como trazer conhecimentos acerca do uso de mensagerias.
Estes so dois exemplos de arquiteturas voltadas para reuso: interoperabilidade

e baixo acoplamento.
Objetivo:
1. Compreender os conceitos gerais e caractersticas da HLA;
2. Entender o funcionamento de mensagerias e sua utilizao com Java.

Contedo
High level architecture

A rea de simuladores sempre apresentou grande complexidade. E muitas
solues para os mesmos problemas seguiam caminhos diferentes, impedindo
que tais solues trabalhassem em conjunto.
1- Muitas simulaes complexas e de grande porte acabam por envolver vrias

simulaes individuais menores.
2 - As simulaes menores eram construdas de forma heterognea, tanto em
termos do tipo de simulao quanto em relao s funcionalidades dos
componentes.
3 - Muitos componentes da simulao j existiam, porm no eram integrveis.
4 - Recriar um componente de simulao, alm de ser caro, representa um
risco maior em termos de testes e estabilidade.
Essa no uma preocupao nova. Como pode ser observado, a ausncia de

um ambiente interopervel e de componentes reutilizveis acaba por encarecer
a construo de um sistema de simulao, bem como demandar mais tempo na
implementao. Alm disso, se fossem utilizados COTS, esses j teriam passado
por vrias fases de teste, diminuindo o risco da implementao final. Partindo
dessas necessidades, e aps diversas iniciativas de integrao e padronizao
de interfaces na rea de simulao militares, foi definido o HLA (high level
architecture):
Um framework genrico com a finalidade de melhorar a

interoperabilidade e reuso de componentes de simulao.
Criado pelo Defense Modeling and Simulation Office (DMSO).
Desenvolvido inicialmente para o Departamento de Defesa dos Estados

Unidos (DoD).

Tornou-se um padro no ano de 2000 (IEEE Standard 1516-2000).
A adoo de HLA promove o reuso de componentes de simulao que podem

vir a ser utilizados em diferentes cenrios e sistemas ao longo de sua vida til.
Permite agrupar simulaes compostas de mltiplos componentes de

simulao;
Integra simulaes distribudas atravs de diferentes plataformas de software
e hardware heterogneo;
Reutiliza sistemas sem mudanas significantes de cdigo ou custo maior de
desenvolvimento;
Combina componentes de simulao com diversos modelos computacionais e
representaes formais.
HLA e RTI
Termos e definies do HLA:

Federate uma aplicao com suporte a HLA que pode participar de
uma simulao nesse ambiente.
Federation a declarao entre federates que definem como e o que

ser simulado.
Federation execution trata de uma instncia de um federation em

execuo, ou seja, a execuo da simulao em si.
Dentro da arquitetura do HLA definida uma infraestrutura de execuo, ou

RTI (run-time infrastructure), que trata basicamente de um framework com as
seguintes caractersticas:
Camada de software que fornece servios comuns aos federates.

A especificao do RTI define as interfaces que os federates precisam acessar
para obter servios e interagir com outros federates.
Essa especificao tambm define qual interface os federates devem expor
para que sejam reconhecidos pelos servios e por outros federates.
Trabalha com tecnologias de simulao legadas, como DIS e ALSP.
Promove uma comunicao eficiente entre federates.
Separa os conceitos de simulao e comunicao.
Independente de linguagem ou plataforma.
Os principais componentes apresentados pela RTI so:
Gesto de federation, que controla as atividades de cada federation durante a

execuo.
Gesto de declaraes, que controla o modelo de publicao e assinatura
para troca de informaes.
Gesto de objetos, controlando todo o ciclo de vida e troca de mensagens
entre esses objetos.

Gesto de responsveis, ou detentores, de forma a viabilizar simulaes
cooperativas atravs da troca de responsabilidade sobre atributos ao longo da
simulao.
Gesto de tempo a qual coordena a linha de tempo de cada federate dentro
do eixo de tempo do federation, garantindo a preservao de causa e
ordenao.
Gesto de dados distribudos, com a transmisso eficiente de dados entre
federates.
Servios de apoio.
Conhea a tabela que resume os servios essenciais de cada componente do

RTI:
Servios essenciais de cada componente do RTI
- Inicializao e trmino da execuo de Federations
- Joining and resigning of federates
Gesto de Federation - Pausa e reincio da execuo do Federation
- Persistncia (armazenagem e recuperao) de

Federation em execuo
- Publicao do objeto e classes de interao
- Resgate de classes de interao
Gesto de declaraes - Resgate de atributos do objeto
- Controle de alteraes
- Controle de interaes

- Registro e localizao de objetos
- Alterao e exposio de atributos de objetos
Gesto de objetos - Envio e recebimento de mensagens de interao
- Remoo de objetos
- Manage transport/ordering
- Assume/divest attribute ownership
Gesto de responsveis - Acquire/release attribute ownership
- Notification of ownership changes
(Federation)
- Sincronizao conservativa
- Sincronizao otimista
- Mtodos hbridos de sincronizao
- Avano de tempo
- Controle de tempo real
Gesto de tempo
(Federate)
- Requisio de avano de tempo
- Notificao de avano concedido
- Requisio do prximo evento
- Notificao de evento concedido
- Gerenciamento da fila de requisies

- Definio da rea de update na publicao
Gesto de dados
- Definio da rea de interesse pelo participante
distribudos
- Gesto das reas de roteamento (intersees)
- Transformao de nome para handle
- Transformao de handle para nome
Servios de apoio - Gesto do sistema de avisos
- Manipulao de regies
- RTI start-up e shutdown
A figura a seguir mostra resumidamente o funcionamento de uma federation.
(Figura ilustrativa do funcionamento de um federation.)

Nos dias atuais, assim como nas arquiteturas orientadas a servio, comum a
adoo de web services para a comunicao na HLA. Na verdade, observando-
se as solues apresentadas pela HLA, fcil perceber como muitos dos
servios de gesto do RTI esto presentes nas arquiteturas de objetos
distribudas e orientadas a servios.
Mensagerias
Uma soluo para a integrao de sistemas complexos com baixssimo
acoplamento o uso de mensagerias. Conhea, 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 atravs dessa mensageria, inclusive de forma assncrona.
O princpio de escrita e leitura assncrona muito comum nas diversas

tecnologias de interao social, como e-mails, mensagens em redes sociais,
mensagens em ambientes mveis, entre muitos outros exemplos. Basicamente,

trata-se de uma arquitetura peer-to-peer com servio centralizado de repasse
de mensagens recebidas e enviadas, servios esse que administra canais
registrados acessveis 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 bancrio.
O que recebemos ao solicitar esse tipo de transao um mero comprovante

da solicitao em si, que enviada para uma mensageria, sendo processada
algum tempo depois pelo banco alvo, sem obrigar o usurio a esperar por esse
processamento, ou, em termos tcnicos, atuando de forma assncrona. Existem
dois modelos de comunicao disponveis nesse ambiente: fila e tpico.
Fila
No modelo de fila, existem muitos destinatrios e apenas um receptor, o qual
pode ou no 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 retm a mensagem at que ela seja consumida, segundo uma ordenao
FIFO (a primeira a entrar a primeira a sair).

(figura representativa de um modelo de Fila)
Tpicos
No modelo de tpicos, podem ocorrer vrios emissores e vrios receptores
simultaneamente. Esse modelo tambm denominado publish-subscribe.
As mensagens so enviadas a um canal (tpico), de onde os assinantes

podero retir-las. Nesse modelo, necessrio um objeto ouvinte (message
listener) para avisar que h nova mensagem no canal.

(figura representativa de um modelo de Tpicos)
Utilizao de mensagerias
O uso de mensagens indicado em situaes especficas.
Quando o elemento principal da comunicao o formato da mensagem, e no

interfaces de programao.
Quando no possvel prever a disponibilidade dos componentes de ambos os

lados, receptor ou emissor.
Quando preciso suportar comunicao assncrona, ou seja, o emissor envia a

informao, mesmo que o receptor no esteja ativo, e no bloqueia suas
operaes.

Ateno
muito comum a adoo de mensagerias em processos B2B

(business to business), ou seja, na comunicao entre sistemas de
empresas distintas, como o caso das instituies bancrias
brasileiras.
Como as mensagerias permitem um melhor controle de acesso,

acabam formando um canal de comunicao privado entre as
empresas, aumentando tambm a segurana da comunicao 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
so EJBs (enterprise java beans), e, como demais componentes dessa
arquitetura, atualmente, podem ser criados com o uso de simples cdigo
anotado Java.

A anotao @MessageDriven define a classe como um MDB, configurando
recurso acessado na mensageria, bem como o tipo de destino (fila ou tpico).
A classe, por sua vez, deve implementar a interface MessageListener, de forma

a tratar as mensagens recebidas em seu mtodo 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 necessrio a postagem de uma mensagem na fila ou
tpico assistido por esse componente.
A arquitetura do JEE e a caracterizao dos demais EJBs sero discutidas

posteriormente nessa disciplina.
(Figura representativa Java EE Server)

Atividade proposta
Como exerccio de fixao, implemente um MDB que receba uma mensagem
composta por dois nmeros 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
Referncias
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 alm,

Editora Casa do Cdigo, 2012.

Exerccios de fixao
Questo 1
O que vem a ser RTI para a High Level Architecture?
a) Uma aplicao com suporte a HLA e que pode participar de simulaes neste
ambiente.
b) Uma simulao em execuo.
c) Apenas um temporizador para as diversas simulaes.
d) Uma mquina virtual para suportar aplicaes Java.
e) Basicamente um framework que garante uma infraestrutura de execuo das
simulaes heterogneas.
Questo 2
Quem foi a entidade responsvel pela criao do HLA?
a) Microsoft
b) MEC
c) Oracle
d) FAB
e) DMSO
Questo 3
Com a Gesto do tempo, o RTI:
a) Controla o modelo de publicao e assinatura para troca de informaes.
b) Permite a transmisso eficiente de dados entre Federates.
c) Coordena a linha de tempo de cada Federate dentro do eixo de tempo do
Federation, garantindo a preservao de causa e ordenao.
d) Controla todo o ciclo de vida e troca de mensagens entre os objetos.
e) Controla as atividades de cada Federation durante a execuo.

Questo 4
O que vem a ser Federate para a High Level Architecture?
a) Uma aplicao com suporte a HLA e que pode participar de simulaes neste
ambiente.
b) Uma simulao em execuo.
c) Apenas um temporizador para as diversas simulaes.
d) Uma mquina virtual para suportar aplicaes Java.
e) Basicamente um framework que garante uma infraestrutura de execuo das
simulaes heterogneas.
Questo 5
No ano de 2000 a High Level Architecture foi transformada em um padro
(standard). Qual foi a entidade normatizadora?
a) DMSO
b) DoD
c) W3C
d) SSL
e) IEEE
Questo 6
Qual das opes abaixo NO um exemplo de mensageria?
a) JBoss MQ
b) IBM MQ Series
c) IPlanet MQ
d) Bea Web Logic
e) QueueSender
Questo 7
Onde imprescindvel um objeto ouvinte (MessageListener) para avisar que
existe uma mensagem no canal da mensageria?
a) Envio do modelo de fila

b) Recepo do modelo de fila
c) Envio do modelo de tpico
d) Recepo do modelo de tpico
e) Preparao prvia da mensagem para envio
Questo 8
Quando o uso de mensagerias NO indicado?
a) Quando o elemento principal da comunicao o formato da mensagem
b) Quando existe a necessidade de bloquear o cliente durante a transao
c) Quando no possvel prever a disponibilidade dos componentes
d) Quando preciso suportar comunicao assncrona
e) Quando necessrio enviar a mensagem, mesmo que o receptor no esteja
ativo
Questo 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
Questo 10
Dentro do ambiente JEE, qual o nome do componente responsvel por receber
as mensagens advindas de uma mensageria?
a) SessionBean
b) Stateless
c) MDB
d) Stateful
e) EntityBean

Aula 2
Exerccios de fixao
Questo 1 - E
Justificativa: A sigla RTI significa Infraestrutura de tempo de execuo, e cuida
do gerenciamento das Federates, Federation e Federation Execution, entre
outros elementos.
Questo 2 - E
Justificativa: Quem criou o HLA foi o Defense Modeling and Simulation Office
(DMSO).
Questo 3 - C
Justificativa: Os componentes responsveis pelas funes citadas nestas opes
so:
Gesto de declaraes, que controla o modelo de publicao e assinatura
para troca de informaes;
Gesto de dados distribudos, com a transmisso eficiente de dados
entre Federates;
Gesto de tempo, o qual coordena a linha de tempo de cada Federate
dentro do eixo de tempo do Federation, garantindo a preservao de causa e
ordenao.
Gesto de objetos, controlando todo o ciclo de vida e troca de
mensagens entre estes objetos;
Gesto de Federation, que controla as atividades de cada Federation
durante a execuo.
Questo 4 - A
Justificativa: Uma aplicao compatvel com o ambiente HLA denominada
Federate.

Questo 5 - E
Justificativa: Inicialmente a HLA foi normatizada pelo IEEE Standard 1516-2000.
Questo 6 - E
Justificativa: A nica opo que no trata de uma mensageria comercial o
QueueSender. Este , na verdade, o componente Java necessrio para enviar
uma mensagem no modelo de fila sem uso de EJBs.
Questo 7 - D
Justificativa: No modelo de tpico necessrio um objeto ouvinte
(MessageListener) para avisar que h nova mensagem no canal, de forma que
os assinantes possam receb-la.
Questo 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
assncrono.
Questo 9 - A
Justificativa: O middleware para acesso a mensagerias denominado MOM, ou
Message Oriented Middleware. As opes RPC e RMI referem-se a sistemas de
processamento distribudo, enquanto JDBC o middleware para acesso a banco
de dados do Java, e o EJB um componente corporativo da plataforma JEE.
Questo 10 - C
Justificativa: O componente responsvel pela recepo das mensagens o
Message Driven Bean, definido pela anotao @MessageDriven, e que precisa
implementar a interface MessageListener.

Introduo
Uma evoluo natural da programao foi a utilizao de processamento
paralelo para a resoluo de problemas complexos.
A distribuio de processamento tambm utilizada com tal finalidade, ou em

situaes nas quais os participantes de uma transao no se encontram
fisicamente no mesmo local.
Esta aula visa elucidar conceitos como processamento paralelo e distribudo,

alm de descrever tecnologias de grande aceitao na implementao de
sistemas distribudos, como RPC e RMI.
Objetivo:
1. Compreender o processamento distribudo e uso do RPC;
2. Conhecer a tecnologia Java RMI.

Contedo
Processamento paralelo
1945
J em 1945, nos trabalhos de Von Neumann, as arquiteturas de processamento
paralelo eram apresentadas como uma soluo para aumento do poder de
processamento.
As tcnicas de processamento paralelo sempre visaram ao melhor

aproveitamento do tempo de CPU, particularmente quando ocorriam
demorados procedimentos de Entrada e Sada.
1950 a 1970
De 1950 a 1970 era comum a utilizao de computadores monoprocessados.
Havia uma busca por processadores cada vez mais velozes, porm existiam
barreiras fsicas para essa velocidade, assim, a soluo mais vivel para a
otimizao do tempo consistiria posteriormente em trabalhar com mquinas
multiprocessadas.
A miniaturizao proporcionada pela evoluo da tecnologia de transistores

permitiu que at mesmo bilhes deles fossem integrados em um chip,
viabilizando a definio de arquiteturas de processadores com mais unidades
funcionais e memria cache.
Com isso, temos hoje processadores com vrios ncleos, com grande poder de
processamento, mais bem explorados pelas tcnicas de programao paralela
com multitarefa.
Em linguagem Java, uma tarefa independente pode ser definida pela extenso
da classe Thread. Outra forma seria a implementao da interface Runnable, o
que no elimina a necessidade da chamada inicial com uma classe Thread. A
tarefa que dever ser executada continuamente em paralelo definida no

mtodo run, e quando h necessidade de sincronizao utiliza-se a palavra-
chave synchronized.
(imagem representativa do mtodo run)

Processamento distribudo
A distribuio de processamento tambm pode ocorrer ao longo de uma rede,
com diferentes processos sendo executados em mquinas remotas, segundo
protocolos especficos de comunicao.
O termo DCE (Distributed Computing Environment) comumente utilizado para

definir esse tipo de ambiente, onde vrios componentes de software, como
servios de diretrios, gestores de segurana, sistemas de objetos distribudos,
entre vrios outros, trabalham em conjunto para a construo de complexos
sistemas corporativos.
Dentro de uma rede TCP-IP, a definio de um servio distribudo de forma

mais simples envolve a construo de um servidor, normalmente trabalhando
com paralelismo, que seja capaz de escutar uma porta especfica destinada ao
servio oferecido, e clientes capazes de se comunicar com esse servidor
segundo um protocolo previamente estabelecido.
Um cdigo em linguagem Java de exemplo para a criao de um sistema

cliente-servidor com uso de Socket.
Embora qualquer sistema cliente-servidor possa atuar dessa forma, algumas

arquiteturas prprias foram definidas para a formalizao dos servios
distribudos, como o RPC e o RMI.

(imagem representativa de um cdigo em linguagem Java)
RPC (Remote Procedure Call)

A chamada remota de procedimento (RPC) trata de um modelo de comunicao
entre processos que viabiliza a chamada de um procedimento em outro espao
de endereamento, normalmente em outro computador da rede, sem que o
programador tenha que se preocupar com detalhes dessa interao remota,
assemelhando-se a chamadas locais em termos de cdigo.
Com isso, o uso de RPC simplifica a criao de sistemas distribudos deixando a

comunicao 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 implementao popular efetuada para UNIX com o Sun RPC, usado
como base para o NFS (Network File System).
Vrias extenses da comunicao remota para ambientes de objetos

distribudos, como CORBA e DCOM, so baseadas em diferentes
implementaes do RPC. As ferramentas para criao de aplicativos RPC
cuidam da gerao dos stubs para garantir essa transparncia.

A ideia fundamental a de que o servidor exporta apenas a interface de
procedimentos e funes, da mesma forma que ocorreria com uma API ou
biblioteca.
O programa cliente faz a chamada ao procedimento remoto, com a passagem

dos parmetros necessrios, e recebe a resposta, como se estivesse chamando
um simples mtodo local.
O par de stubs faz a transformao de chamadas e respostas nas mensagens

necessrias para a comunicao em rede. Em termos do servidor, esse
elemento responsvel pela interceptao das chamadas comumente
denominado skeleton, e deve receber a chamada, ativar o componente de
software responsvel pelo processamento do pedido, e retornar com a resposta
solicitada.
Com todas essas caractersticas, o nico vnculo real entre o cdigo do cliente e
o do servidor a interface de exposio de servios, a qual segue uma sintaxe
bastante simples.
Um exemplo de sistema com uso de RPC na sintaxe C, bem como a interface de

exposio dos servios:
/* addsub.x : definio 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;

};
/* Definio 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 utilitrio rpcgen so gerados vrios arquivos a partir desse

arquivo de interface, compreendendo toda a parte de comunicao e oferta de
servios, o que deixar para o programador a simples tarefa de implementar as
regras de negcios do aplicativo, sem se desgastar com a comunicao e
distribuio.
/* Arquivo server.c: um servidor RPC simples */

#include <stdio.h>
#include "addsub.h"
/* implementao da funo 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);
}
/* implementao da funo sub */

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 cdigo do cliente um pouco mais complexo que o do servidor, mas fcil

observar como a chamada remota assemelha-se a uma simples chamada de
funo local.
/* Arquivo client.c: um cliente RPC simples */
#include <stdio.h>
#include "addsub.h"
/* funo que chama a RPC add_1 */

int add (CLIENT *clnt, int x, int y)
{
operands ops;
int *result;
/* junta os parmetros em um struct */

ops.x = x;
ops.y = y;
/* chama a funo remota */

result = add_1 (&ops,clnt);
if (result == NULL)
{
printf ("Problemas ao chamar a funo remota\n");
exit (1);
}
return (*result);
}
int main( int argc, char *argv[])

{
CLIENT *clnt;
int x,y;

/* 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 referncia foi criada */

if (clnt == (CLIENT *) NULL)
{
clnt_pcreateerror (argv[1]);
exit(1);
}
/* obtm os dois inteiros que sero 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 definio dos servios (IDL).)
RM(Remote Method Invocation)

A tecnologia RMI pode ser considerada como a verso orientada a objetos do
RPC, disponvel para a linguagem Java.
Nesse modelo o que temos um objeto hospedado e executado em

determinado servidor, registrado via RMI Registry, e que disponibiliza mtodos
para acesso remoto.
A arquitetura de comunicao do RMI pode ser observada no desenho seguinte,

onde pode ser vista a presena dos stubs nos clientes e do skeleton no
servidor.

(imagem representativa da tecnologia RMI)
O passo inicial para o desenvolvimento de um sistema com uso de RMI a

definio da interface remota, o que equivaleria definio da IDL utilizada no
RPC, porm restrita ao universo Java.
Essa interface dever ser descendente da interface Remote e cada mtodo dela
dever considerar a ocorrncia da exceo RemoteException, como pode ser
observado no exemplo seguinte:

Criada a interface, deve ser definido um objeto servidor que a implementa,
criando assim os mtodos do servio.
Esse objeto tambm deve ser descendente de UnicastRemoteObject.
Um objeto da classe CalcRemote deve ser instanciado e registrado pelo

programa servidor, ficando disponvel para os clientes atravs da escuta
efetuada pelo RMI Registry.

Com relao ao cliente, este dever localizar o objeto servidor atravs do
protocolo gerenciado pelo RMI Registry, efetuando a chamada aos mtodos
remotos, segundo o que foi definido em ICalcRemote.
O uso de RMI permite a definio de um DCE de grande simplicidade de uso

para a linguagem Java, permitindo a passagem de informaes atravs de
objetos serializveis mais complexos, segundo um padro Proxy, diminuindo
muito o esforo de programao.
No entanto, quando so tratados os sistemas corporativos, vrios requisitos,

como transaes, pooling e autenticao, podem no ser oferecidos de forma
simples pelo RMI. Para satisfazer a esse tipo de necessidade so utilizados
ambientes de objetos distribudos.
Marshalling e Unmarshalling
Um conceito comum em termos de programao orientada a objetos a
serializao de objetos.
A serializao a transformao de dados em geral, que estejam em memria,

para um formato adequado em array de bytes, pronto para armazenagem ou
transferncia do mesmo.

Em outro momento o processo inverso (desserializao) pode ser efetuado,
partindo do array de bytes e montando a estrutura novamente em memria,
claro que ocupando locais diferentes da mesma.
Em termos de comunicao remota, um conceito similar o de Marshalling e

Unmarshalling, pois trata da transformao dos dados estruturados segundo
uma determinada tecnologia, como Java ou C#, em formato compatvel com as
mensagens que so trafegadas entre os stubs (Marshalling), bem como o
processo inverso, para a recuperao dos dados a partir da mensagem
(Unmarshalling), lembrando que nas duas pontas as linguagens podem ser
distintas.
Servios de nomes e diretrios

A chamada remota de procedimento (RPC) trata de um modelo de comunicao
entre processos que viabiliza a chamada de um procedimento em outro espao
de endereamento, normalmente em outro computador da rede, sem que o
programador tenha que se preocupar com detalhes dessa interao remota,
assemelhando-se a chamadas locais em termos de cdigo.
Associam nomes a recursos computacionais em rede;
Funcionam como diretrios compartilhados;
Envolvem funes de localizao e registro de elementos;
Permitem armazenar objetos, certificados digitais e outros elementos

serializveis.
Amplamente utilizados pelas instituies bancrias, DAP (Directory Access

Protocol) e LDAP (Lightweight Directory Access Protocol) so exemplos desse
tipo de servio. No caso da tecnologia Java, as aes de registro e localizao
so feitas pelo JNDI (Java Naming and Directory Interface), o qual apresenta

uma interface nica entre os diversos servios de diretrio, gerenciando
inclusive o acesso a recursos como RMI, CORBA, DAP, LDAP e JEE.
Atividade proposta
Implemente um servio RMI que receba o valor de dois catetos de um tringulo
retngulo e retorne o valor da hipotenusa.
Parmetros de entrada: double cateto1, double cateto2
Retorno: double
Clculo: hipotenusa = Math.sqrt(Math.pow(cateto1,2)+Math.pow(cateto2,2))
Referncias
Silva, F. Sistemas Distribudos: 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), OReilly, 2001.

Exerccios de fixao
Questo 1
Quando trabalhamos com processamento paralelo, um problema comum a
utilizao de recursos compartilhados que podem ser lidos ou escritos de forma
errnea devido preempo. 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
Questo 2
Uma classe ServerSocket deve escutar uma porta especificada e aceitar
conexes solicitadas pelos clientes, repassando as mesmas para objetos Socket
locais, o que define o circuito virtual entre cliente e servidor. Qual o mtodo
utilizado para aceitar uma conexo?
a) start
b) accept
c) getInputStream
d) getOutputStream
e) close
Questo 3
A utilizao de RPC viabiliza a construo de sistemas de processamento
distribudo com um formato de comunicao transparente para o programador.
Quem permite esta transparncia so os _______________ definidos para o
padro Proxy.
a) senders
b) idles
c) clients

d) stubs
e) publishers
Questo 4
Na arquitetura do RPC, o elemento responsvel por tratar as chamadas no
servidor denominado:
a) IDL
b) stub
c) skeleton
d) Socket
e) ServerSocket
Questo 5
O elemento na arquitetura do RPC que permite a gerao automtica de todo o
aparato de comunicao em rede, de forma automatizada, por ferramentas
como o rpcgen :
a) IDL
b) stub
c) skeleton
d) Socket
e) ServerSocket
Questo 6
Em sistemas de processamento distribudo ocorre a necessidade de registrar e
localizar componentes disponibilizados remotamente. O componente de
software responsvel por executar esta funo seria:
a) Interface de Descrio de Servios
b) Servio de Nomes e Diretrios
c) Temporizador
d) Protocolo de Comunicao
e) Gerenciador do Banco de Dados

Questo 7
A transformao dos dados estruturados segundo uma determinada tecnologia,
como Java ou C#, em formato compatvel com as mensagens que so
trafegadas entre os stubs denominada:
a) serializao
b) unmarshalling
c) marshalling
d) de-serializao
e) vetorizao
Questo 8
Em termos de RMI a descrio dos servios feita na prpria linguagem Java
atravs de uma interface descendente de:
a) Remote
b) Runnable
c) MessageListener
d) Serializable
e) CommandListener
Questo 9
Considere as afirmativas abaixo:
I Os mtodos expostos pela interface remota do RMI devem considerar a
ocorrncia da exceo 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 so necessrios e suficientes para a criao de um
servidor RMI.
Quais as afirmativas corretas?
a) Todas esto corretas
b) Apenas a I est correta
c) Apenas a II est correta
d) As alternativas I e II esto corretas

e) Nenhuma est correta
Questo 10
No ambiente Java os servios de nomes e diretrios so acessados atravs de:
a) DAP
b) LDAP
c) DNS
d) JEE
e) JNDI

Aula 3
Exerccios de fixao
Questo 1 - C
Justificativa: Em linguagem Java uma tarefa independente pode ser definida
pela extenso da classe Thread ou pela implementao da interface Runnable,
e quando h necessidade de sincronizao utiliza-se a palavra-chave
synchronized.
Questo 2 - B
Justificativa: Os mtodos getInputStream, getOutputStream e close pertencem
classe Socket, enquanto start inicia uma Thread. O mtodo accept pertence
ao ServerSocket e serve para receber uma conexo na porta especificada na
inicializao do mesmo.
Questo 3 - D
Justificativa: As ferramentas para criao de aplicativos RPC cuidam da gerao
dos stubs para garantir a transparncia da comunicao em rede. O par de
stubs faz a transformao de chamadas e respostas nas mensagens
necessrias.
Questo 4 - C
Justificativa: Em termos do servidor, o elemento responsvel pela interceptao
das chamadas comumente denominado skeleton, e deve receber a chamada,
ativar o componente de software responsvel pelo processamento do pedido, e
retornar com a resposta solicitada.
Questo 5 - A
Justificativa: A utilizao de Socket e ServerSocket de forma plana no
constituiria um sistema RPC. Nas arquiteturas do tipo RPC deve haver uma IDL

(Interface Definition Language) que permita a aplicativos como o rpcgen gerar
os stubs para a comunicao com o skeleton do servidor.
Questo 6 - B
Justificativa: Tanto no uso de RMI quanto no uso de CORBA, JEE, ou qualquer
outro recurso que precise ser acessado a partir de uma localizao externa ao
programa que fornece este recurso, comum o uso de servios de nomes e
diretrios.
Questo 7 - C
Justificativa: A transformao dos dados para o formato de envio denominada
marshalling, enquanto o processo inverso, na recepo, denominado
unmarshalling.
Questo 8 - A
Justificativa: O passo inicial para o desenvolvimento de um sistema com uso de
RMI a definio da interface remota, o que equivaleria definio da IDL
utilizada no RPC, porm restrita ao universo Java. Esta interface dever ser
descendente da interface Remote.
Questo 9 - D
Justificativa: A alternativa III est incorreta, pois seria ainda necessrio criar
um aplicativo (main) que registre uma instncia da classe criada em II, bem
como o rmiregistry dever estar em execuo para que este aplicativo consiga
tambm executar.
Questo 10 - E
Justificativa: No caso do Java, as aes de registro e localizao so feitas pelo
JNDI, o qual apresenta uma interface nica entre os diversos servios de
diretrio, gerenciando inclusive o acesso a recursos como RMI, CORBA, DAP,
LDAP e JEE.

Introduo
Com as necessidades corporativas em termos de processamento, cooperao,
transaes e segurana, comeam a aparecer diversas plataformas de objetos
distribudos.
A principal plataforma utilizada originalmente era o CORBA, arquitetura aberta

que permite s mais diversas plataformas acessarem seus componentes de
forma remota.
No mundo Java surgem os EJBs (Enterprise Java Beans), objetos distribudos

com acesso irrestrito s tecnologias Java, e que mantm compatibilidade com
tecnologias legadas atravs de uma camada de comunicao compatvel com
CORBA.
Objetivo:
1. Compreendeu os objetos distribudos e uso de CORBA;
2. Entendeu a arquitetura do JEE e sua interoperabilidade com CORBA.

Contedo
Objetos distribudos
Em termos de orientao a objetos, uma Interface define um conjunto bem-
definido de mtodos pblicos que viabilizam o acesso e uso externo.
Uma referncia a um objeto trata-se de um ponteiro de memria, onde o

acesso ao estado do objeto feito atravs de sua interface, que deve ser a
nica parte visvel do objeto.
A forma como a interface implementada no se torna relevante para o

sistema como um todo, pois define apenas uma fronteira que viabiliza a troca
de mensagens entre objetos distintos.
Quando os objetos esto em mquinas distintas e oferecem suas interfaces

para acesso atravs da rede, isso define a base do conceito de objetos
distribudos.
Caractersticas de objetos distribudos:

Interagem atravs da rede;
Atuam de forma colaborativa;
Apenas a interface do objeto pode ser acessada e de forma remota;
A interface define os servios oferecidos;
Para referenciar o objeto necessrio o endereo de rede;
Comunicam-se segundo o padro de desenvolvimento Proxy.
As solues que implementam objetos distribudos geralmente tm uma

estrutura que consiste de:
Servio de registro de objetos: servio que mapeia um nome a um objeto
para que possa ser localizado pelas aplicaes que querem usar seus servios;

Interface de comunicao: documento ou classe que declara a interface
(mtodos, parmetros, tipos de retorno etc.) que podem ser chamados no
objeto. o principal instrumento de interoperabilidade;
Infraestrutura de comunicao: barramento que utiliza um protocolo comum,
stubs que encapsulam cdigo de rede do cliente e skeletons que encapsulam
servidores;
Formato de dados comuns usado na comunicao.
Alguns exemplos de arquiteturas de objetos distribudos so:

CORBA, tecnologia de objetos distribudos, definida pelo OMG
(http://www.omg.org) que utiliza para comunicao o protocolo IIOP;
DCOM, tecnologia da Microsoft para objetos distribudos;
JEE, tecnologia Java para objetos distribudos baseada no protocolo RMI-
IIOP;
DDObjects, framework de objetos distribudos utilizado pelo Delphi;
Pyro, framework de objetos distribudos que utiliza Python;
Objetos distribudos
Objetos distribudos normalmente so utilizados em solues corporativas,
sendo instanciados em pools do lado servidor e acessados remotamente por
clientes, os quais podem ser tambm outros servidores. Em termos gerais,
objetos locais e distribudos diferem em vrios aspectos.
- Ciclo de vida: criao, migrao e excluso de objetos distribudos so

diferentes de objetos locais.
- Referncia: referncias remotas a objetos distribudos so mais complexas do
que os ponteiros simples para endereos de memria.
- Latncia do pedido: uma solicitao de objetos distribudos mais lenta do que
a invocao de mtodos locais.
- Ativao do objeto: objetos distribudos podem no estar sempre disponveis
para servir uma solicitao de objeto em qualquer instante.
- Paralelismo: comum objetos distribudos serem executados em paralelo.

- Comunicao: h diferentes primitivas de comunicao disponveis para
solicitaes de objetos distribudos.
- Falha: objetos distribudos tm muito mais pontos de falha que objetos tpicos
locais.
- Segurana: distribuio aumenta a vulnerabilidade a ataques, exigindo
ferramentas prprias de autenticao e uso.
CORBA
Criado pelo OMG (Object Management Group), o CORBA (Common Object
Request Broker Architecture) trata de uma arquitetura padro com o objetivo
de estabelecer e simplificar a troca de dados entre sistemas distribudos
heterogneos baseados em objetos.
O grande diferencial do CORBA frente a outros sistemas de objetos distribudos

a preocupao em garantir a interoperabilidade, pois as suas interfaces de
exposio de servios seguem uma sintaxe independente, e plataformas como
Java e dotNet apresentam ferramentas prprias para gerar os stubs de forma
automatizada, deixando a comunicao transparente ao programador, segundo
o padro Proxy.

Essa interface de exposio de servios denominada CORBA-IDL e segue uma
sintaxe muito parecida com a da linguagem C, como pode ser observado no
exemplo da tela:
module Finance {
struct CustomerDetails {
string name;
short age;
};
interface Bank {
CustomerDetails getCustomerDetails;
(in string name);
};
};
Esses arquivos em CORBA-IDL formam um repositrio, ou catlogo, de como os

servios devem ser utilizados pelas mais diversas linguagens.
No vocabulrio do CORBA, um ORB (Object Request Broker) trata de um

componente de software que funciona como um mediador entre o cliente ou
servidor e o canal de comunicao especificamente, o qual utiliza IIOP (Internet
Inter-ORB Protocol) como protocolo padro.
Ateno
Em termos prticos, o uso de ORB pelo CORBA define um

midleware mais estratgico e mais sofisticado conceitualmente
que outros midlewares, como RPC e MOM. Entre as
caractersticas de um ORB encontram-se:
Servios de gerenciamento do ciclo de vida, incluindo criao,

cpia, movimentao e deleo de alguns componentes;

Servio de persistncia, incluindo a possibilidade de utilizao
de banco de dados;
Sistema de eventos, que permitem aos componentes

especificarem quais eventos devero ser notificados;
Controle de concorrncia;
Servios transacionais, permitindo desfazer alteraes no

confirmadas;
Servio de nomes e diretrios para localizao de componentes

(COS Naming, ou Common Object Service Naming Services);
Opcionalmente um ORB pode apresentar tambm servios de

segurana e Time Stamp.
RMI-IIOP
A principal arquitetura de objetos distribudos comercial do Java o JEE (Java
Enterprise Edition) com seus componentes, denominados EJBs (Enterprise Java
Beans), e essa arquitetura utiliza um protocolo de comunicao denominado
RMI-IIOP. Mas qual o motivo para se utilizar uma camada IIOP, se a
comunicao remota padro para servios distribudos do Java o RMI?
A resposta simples: o uso de IIOP, pelo fato do CORBA-IDL garantir a

interoperabilidade com diversas linguagens, permite a ferramentas como Delphi
e C++ utilizarem os servios oferecidos pelo Java na plataforma JEE. O Java
apresenta ferramentas para transformao direta do cdigo-fonte das interfaces

RMI-IIOP em CORBA-IDL, facilitando ainda mais a disponibilizao para outras
plataformas. Inicialmente, deve ser criada a interface remota, da mesma forma
que o RMI.
Porm, para que a implementao esteja compatvel com o CORBA, segundo o

protocolo IIOP, deve ser utilizado um descendente de PortableRemoteObject.
A partir desta implementao do objeto remoto, podem ser gerados o Stub e o

Skeleton com o comando rmic -iiop exemplormi.CalcRemoteCORBA, e
opcionalmente pode ser gerada a IDL atravs do comando rmic -iiop -idl
exemplormi.CalcRemoteCORBA, o que ir gerar um arquivo IDL com o
contedo a seguir, permitindo a chamada do objeto remoto a partir de outras
ferramentas, como Delphi e C++, segundo os princpios de interoperabilidade
defendidos no contexto de arquiteturas orientadas a servio.
/**
* exemplormi/ICalcRemote.idl

* Generated by rmic -idl. Do not edit
* Quinta-feira, 20 de Agosto de 2015 09h58min41s BRT
*/
#include "orb.idl"
#ifndef __exemplormi_ICalcRemote__
#define __exemplormi_ICalcRemote__
module exemplormi {
interface ICalcRemote {
long add(
in long arg0,
in long arg1 );
long sub(
in long arg0,
in long arg1 );
};
#pragma ID ICalcRemote "RMI:exemplormi.ICalcRemote:0000000000000000"
};
#endif
atravs desse arquivo IDL, criado pelo rmic, que ferramentas de apoio a
tecnologias, como Visual Studio dotNet, podem gerar os clientes CORBA de
forma simplificada.

Java Enterprise Edition
A arquitetura JEE baseada em componentes denominados Enterprise Java
Beans, os quais so instanciados em pools de objetos no servidor,
disponibilizando atravs de fbricas registradas as interfaces de acesso remoto
ou local a esse pool.
Como descrito anteriormente, essa arquitetura define uma forma de

interoperabilidade com tecnologias legadas com suporte CORBA atravs do
uso de RMI-IIOP para a camada de comunicao.
Um Enteprise JavaBean (EJB) um componente que pode ser implantado em

um servidor de aplicaes e utilizar seus servios de forma declarativa ou no.
O servidor oferece o container que executa o componente;
O container gera os interceptadores que isolam esse componente dos

seus clientes locais ou remotos;
O deployer (instalador da aplicao) pode configurar os servios que

desejar e o cdigo para cham-los ser gerado nos interceptadores
durante a implantao;
Um EJB um objeto distribudo, mas no um objeto remoto. No

entanto, seu interceptador pode ser um, caso utilize RMI-IIOP.
Ateno
Embora as anotaes includas na verso JEE5 tenham

simplificado muito a construo de aplicativos corporativos com
Java, na verso J2EE a arquitetura do framework ficava mais
acessvel ao programador, permitindo entender a filosofia bsica

do JEE.
Em termos gerais, os EJBs so instanciados em pools no

servidor, sendo acionados atravs de interfaces locais ou
remotas, criadas a partir de fbricas prprias.
A figura seguinte mostra o funcionamento da arquitetura JEE. Nenhum EJB

pode ser acessado diretamente. Para os clientes remotos, estes devem acessar
a fbrica remota (EJBHome) e solicitar uma interface de acesso ao Pool de EJBs
de forma remota, a qual ser um EJBObject, enquanto para os clientes locais
devem utilizar a fbrica local (EJBLocalHome) para a criao de interfaces de
acesso similares, mas que trabalham localmente, sendo derivadas de
EJBLocalObject.
(figura representativa da arquitetura JEE)
O modelo de criao de interfaces, em ambos os casos, segue o padro

Abstract Factory, enquanto a comunicao de EJBObject segue o padro Proxy
com protocolo RMI-IIOP, e os pools de EJBs seguem o padro Fly Weight. Alm
desses, vrios outros padres de desenvolvimento esto presentes no JEE.
Como as fbricas so nicas para cada classe de EJB especfica, elas so

nomeadas e acessadas via JNDI, o que denota a presena de um padro

Singleton implcito. Os padres de desenvolvimento presentes na arquitetura
J2EE podem ser observados na figura em questo.
Existem trs tipos de EJBs:
SessionBean, para processos de negcios sncronos;

EntityBean, para persistncia;
Message Driven Bean (MDB), para processos de negcios assncronos;
O nico tipo de EJB que no segue o modelo de ativao descrito, com o uso
de fbricas de interfaces, o MDB, pois ele ativado atravs do JMS, conforme
visto em aulas anteriores desta disciplina.
Quanto aos EntityBeans, foram substitudos pelo JPA (Java Persistence

Architecture) no JEE5 devido a questes de performance.
Finalmente, os SessionBeans podem ser divididos em dois tipos distintos:
- Stateless, os quais no guardam estado entre transaes sucessivas;

- Stateful, que ao contrrio dos primeiros, guarda estado entre transaes.

O cdigo seguinte demonstra a criao de um EJB Stateless, segundo a sintaxe
anotada do JEE5, bem como suas interfaces (local e remota). Observa-se que,
com o uso de anotaes, a codificao das fbricas foi suplantada, tornando-se
responsabilidade do Application Server.
Para que este EJB seja utilizado a partir de um Servlet, por exemplo, bastaria
acrescentar um atributo anotado do tipo CalculadoraLocal, como no cdigo
abaixo:

Chamada de JEE por ferramentas CORBA
possvel utilizar o J2EE (Java 2 Enterprise Edition) para gerar EJBs acessveis
a partir de outras plataformas com suporte a CORBA. Nessa verso do JEE os
componentes no so anotados, sendo sua programao levemente mais
trabalhosa que as verses a partir do JEE5.
// Interface remota que utiliza o protocolo RMI-IIOP

public interface Logger extends EJBObject
{
void logString(String message) throws RemoteException;
}
// Fbrica de interfaces remotas
public interface LoggerHome extends EJBHome
{
Logger create() throws RemoteException, CreateException;}
O exemplo aqui utilizado est disponvel na documentao da Oracle, no

endereo
http://docs.oracle.com/javase/7/docs/technotes/guides/rmi-

iiop/interop.html. Inicialmente devem ser criados a interface remota do EJB
e tambm a fbrica de interfaces remotas.
Aps a definio desses componentes, o EJB em si deve ser criado, nesse caso
um SessionBean.
Para efetuar o deploy deste EJB seria necessrio ainda a configurao nos
arquivos XML corretos. Com relao interoperabilidade via IIOP, o passo
seguinte seria a gerao dos arquivos IDL atravs do programa rmic.
Chamada de JEE por ferramentas CORBA

Com relao interoperabilidade via IIOP, o passo seguinte seria a gerao dos
arquivos IDL atravs do programa rmic, conforme o modelo abaixo:
rmic -idl -noValueMethods classpath

$J2EE_HOME/lib/j2ee.jar:<diretorio_codigo_fonte>
-d <diretrio_geracao_idl> ejbinterop.Logger ejbinterop.LoggerHome
Sero gerados os seguintes arquivos, lembrando que apenas dois so

especficos para esse EJB (Logger.idl e LoggerHome.idl), sendo os demais
apenas arquivos padro de suporte comunicao com o J2EE:
java/lang/Ex.idl
java/lang/Exception.idl
java/lang/Object.idl
java/lang/Throwable.idl
java/lang/ThrowableEx.idl
javax/ejb/CreateEx.idl
javax/ejb/CreateException.idl
javax/ejb/EJBHome.idl
javax/ejb/EJBMetaData.idl
javax/ejb/EJBObject.idl

javax/ejb/Handle.idl
javax/ejb/HomeHandle.idl
javax/ejb/RemoveEx.idl
javax/ejb/RemoveException.idl
ejbinterop/Logger.idl
ejbinterop/LoggerHome.idl
Com uma ferramenta adequada o arquivo-cliente pode ser gerado, como por
exemplo, o cdigo abaixo que foi gerado em C++ pelo ORBacus 4.0.5. Os
comentrios gerados foram suprimidos para evitar uma quantidade maior de
linhas no exemplo.
#include <fstream.h>
#include <OB/CORBA.h>
#include <OB/OBORB.h>
#include <java/lang/Exception.h>
#include <java/lang/Throwable.h>
#include <javax/ejb/CreateException.h>
#include <javax/ejb/RemoveException.h>
#include <ejbinterop/Logger.h>
#include <ejbinterop/LoggerHome.h>
void run(CORBA::ORB_ptr orb, const char* logger_home_url)

{
cout << "Looking for: " << logger_home_url << endl;
CORBA::Object_var home_obj = orb->string_to_object(logger_home_url);
ejbinterop::LoggerHome_var home =
ejbinterop::LoggerHome::_narrow(home_obj.in());
assert(!CORBA::is_nil(home));
ejbinterop::Logger_var logger = home->create();
CORBA::WStringValue_var msg =

new CORBA::WStringValue((const CORBA::WChar*)L "Message from a
C++ client");
cout << "Logging..." << endl;
logger->logString(msg);
logger->remove();
cout << "Done" << endl;
}
int main(int argc, char* argv[])

{
int exit_code = 0;
CORBA::ORB_var orb;
try {
if (argc != 2) {
cerr << "Usage: Client <corbaname URL of LoggerHome>" << endl;
return 1;
}
orb = CORBA::ORB_init(argc, argv);

CORBA::ValueFactory factory = new java::lang::Throwable_init;
orb -> register_value_factory(java::lang::Throwable::_OB_id(),factory);
factory -> _remove_ref();
factory = new java::lang::Exception_init;
orb -> register_value_factory(java::lang::Exception::_OB_id(),factory);
factory = new javax::ejb::CreateException_init;
orb -> register_value_factory(javax::ejb::CreateException::_OB_id(),factory);
factory = new javax::ejb::RemoveException_init;
orb -> register_value_factory(javax::ejb::RemoveException::_OB_id(),
factory);

run(orb, argv[1]);
} catch(const CORBA::Exception& ex) {

cerr << ex._to_string() << endl;
exit_code = 1;
}
if (!CORBA::is_nil(orb)) {
try {
orb -> destroy();
} catch(const CORBA::Exception& ex) {
cerr << ex._to_string() << endl;
exit_code = 1;
}
}
return exit_code;
}
Embora o cdigo seja um pouco extenso, ele gerado automaticamente a

partir dos arquivos IDL, o que significa que no envolve grande custo em
termos de desenvolvimento.
Por fim, a classe gerada pode ser compilada em algum compilador C++, e o
cliente pode ser chamado passando o endereo onde pode ser acessada a
fbrica de interfaces do SessionBean, como no exemplo seguinte:
Client corbaname:iiop:1.2@localhost:1050#ejbinterop/logger
Esse tipo de soluo um grande elemento de interoperabilidade com

tecnologias legadas, apresentando-se como soluo bastante vivel na
integrao com mainframes.

public class LoggerEJB implements SessionBean {
public LoggerEJB() {}
public void ejbCreate() {}
public void ejbRemove() {}
public void ejbActivate() {}
public void ejbPassivate() {}
public void setSessionContext(SessionContext sc) {}
public void logString(String message) {
System.out.println(new Date() + "::" + message);
}
}
Atividade proposta
Como atividade de fixao, efetue uma pesquisa acerca de padres de
desenvolvimento e como os mesmos so aplicados em arquiteturas de objetos
distribudos como o JEE e o CORBA.
Referncias
McHale, C. CORBA explained simply, 2007
http://www.ciaranmchale.com/download/corba-explained-
simply.pdf
Burke, B. Monson-Haefel, R. Enterprise Java Bens 3.0, Editora OReilly, 2007.

Exerccios de fixao
Questo 1
Qual o padro de desenvolvimento utilizado na forma de comunicao com
objetos distribudos?
a) Front Control
b) Flyweight
c) DAO
d) Proxy
e) Request Dispatcher
Questo 2
Qual o servio de nomes e diretrios do CORBA?
a) CORBA IDL
b) LDAP
c) DNS
d) JNDI
e) COS Naming
Questo 3
Qual a entidade responsvel pela criao do CORBA?
a) DoD

b) OMG
c) DMSO
d) W3C
e) IEEE
Questo 4
Qual das opes abaixo NO uma arquitetura de objetos distribudos?
a) CORBA
b) JEE
c) DDObjects
d) COM
e) Pyro
Questo 5
Para que um servidor RMI possa se tornar compatvel com o protocolo IIOP,
segundo a especificao RMI-IIOP, a classe de negcios deve ser definida como
um descendente de:
a) PortableRemoteObject
b) UnicastRemoteObject
c) MulticastRemoteObject
d) HttpServlet
e) RemoteException
Questo 6
Qual o elemento que viabiliza a compatibilidade com CORBA para os EJBs?
a) Descrio de servios CORBA-IDL
b) Protocolo RMI-IIOP
c) Uso da linguagem Java
d) Uso do JNDI
e) Padro Proxy
Questo 7

Qual a anotao que deve ser utilizada para efetuar a chamada ao pool de EJBs
a partir de um Servlet?
a) @Local
b) @Remote
c) @Stateless
d) @Stateful
e) @EJB
Questo 8
Qual tipo de EJB era utilizado no J2EE para efetuar a persistncia de dados?
a) Message Driven Bean
b) Stateless SessionBean
c) Stateful SessionBean
d) EntityBean
e) EntityManager
Questo 9
Um descendente de EJBHome deve gerar descendentes de EJBObject para
prover acesso remoto ao pool de EJBs, enquanto descendentes de
EJBLocalHome devem gerar descendentes de EJBLocalObject para prover
acesso local ao mesmo pool. Para tal finalidade utilizado o padro de
desenvolvimento:
a) Proxy
b) Flyweight
c) Abstract Factory
d) Session Facade
e) DAO
Questo 10
Considere as seguintes afirmativas:
I A construo de pools de EJBs baseada no padro Flyweight.
II A comunicao remota com os EJBs feita segundo o padro Proxy.

III No J2EE tornou-se uma prtica comum a adoo de um componente que
siga o padro Service Locator para localizar as fbricas de EJBs.
Quais esto corretas?
a) Apenas as afirmativas I e II
b) Apenas a afirmativa I
c) Apenas a afirmativa II
d) Apenas a afirmativa III
e) Todas as afirmativas

Aula 4
Exerccios de fixao
Questo 1 - D
Justificativa: O padro Proxy adotado, j que so utilizados stubs e skeletons
na comunicao entre cliente e servidor. Os demais padres: Front Control
utilizado na camada de visualizao para direcionamento de requisies
apenas; Flyweight utilizado nos pools de objetos; DAO trabalha na camada de
dados, concentrando o acesso ao banco; e Request Dispatcher efetua
redirecionamentos para visualizaes especficas.
Questo 2 - E
Justificativa: No ambiente CORBA o servio de nomes e diretrios para
localizao de componentes denominado COS Naming, ou Common Object
Service Naming Services.
Questo 3 - B
Justificativa: Criado pelo OMG (Object Management Group), o CORBA (Common
Object Request Broker Architecture) trata de uma arquitetura padro com o
objetivo de estabelecer e simplificar a troca de dados entre sistemas
distribudos heterogneos baseados em objetos.
Questo 4 - D
Justificativa: O formato COM server para arquivos binrios compatveis com a
interface interopervel de componentes Microsoft. Para utilizar objetos
distribudos seria adotada uma tecnologia similar, porm com suporte ao
ambiente distribudo, denominada DCOM.
Questo 5 - A
Justificativa: Os passos para colocar um sistema RMI sob o IIOP segue os
mesmos passos de um RMI padro, porm, para que a implementao esteja

compatvel com o CORBA, segundo o protocolo IIOP, deve ser utilizado um
descendente de PortableRemoteObject na criao da classe de negcios.
Questo 6 - B
Justificativa: Incialmente, a descrio de servios para os EJBs utiliza Java, e
no CORBA-IDL. O padro proxy apenas o modelo de comunicao baseado
em stubs, e o uso de Java ou JNDI no traz qualquer compatibilidade com o
ambiente CORBA. O protocolo RMI-IIOP o que traz esta compatibilidade.
Questo 7 - E
Justificativa: Para que este EJB seja utilizado a partir de um Servlet bastaria
acrescentar um atributo do tipo da interface escolhida (remota ou local),
anotado com @EJB. As demais anotaes esto relacionadas criao
SessionBeans e suas interfaces.
Questo 8 - D
Justificativa: Os EntityBeans eram utilizados para persistncia, mas foram
substitudos pelo JPA no JEE5 por questes de performance. Quanto ao
EntityManager, ele se refere gesto de entidades anotadas do JPA. Os
SessionBeans trabalham com processos de negcios sncronos, e os MDBs
trabalham com recepo de mensagerias.
Questo 9 - C
Justificativa: Segundo o padro Abstract Factory, toda a funcionalidade bsica
de integrao com o framework fica pronta, enquanto o desenvolvedor
especializa apenas para a fbrica concreta e interface concreta os detalhes
referentes a regras de negcio prprias do aplicativo. Quanto ao Proxy,
utilizado na comunicao, o Flyweight na gesto dos pools de EJBs, o
SessionFacade seria um Session encapsulando as chamadas aos EntityBeans ou
JPA, e finalmente o DAO poderia ser utilizado para organizar as funes de
persistncia.

Questo 10 - E
Justificativa: Todas as afirmativas esto corretas. Particularmente quanto
afirmativa III, no JEE5 a adoo de anotaes como @EJB acabou eliminando a
necessidade de utilizar o Service Locator.

Introduo
O formato de transferncia de dados que foi adotado mundialmente como
padro, devido a caractersticas como transparncia aos firewalls e facilidade de
escrita, o da sintaxe XML.
Como a sintaxe XML no define regras sobre os dados envolvidos, a definio

de gramticas torna-se necessria para aplicaes de domnio especfico, o que
leva ao surgimento do DTD e do XSD.
Por fim, muitas vezes necessrio transformar o XML de origem para outro
formato, seja para visualizao ou para compatibilizao entre sadas e
entradas, tornando-se teis nesse contexto linguagens como XSLT e XSL-FO.
Objetivo:
1. Apresentar a sintaxe XML e definio de gramticas;
2. Apresentar as linguagens de transformao.

Contedo
Sintaxe XML
Apesar de tratar apenas de uma maneira de representar a informao, a
sintaxe XML (eXtensible Markup Language) acabou se tornando base para a
maioria dos recursos de configurao e conectividade das ferramentas
disponveis do mercado, bem como elemento essencial para a troca de dados
entre plataformas distintas.
A histria do XML comeou com uma iniciativa da IBM que, nos anos 70, para
definir uma metodologia de armazenamento de grandes quantidades de
informaes, criou o GML (General Markup Language), a qual foi padronizada
pela ISO (International Organization for Standardzation) em 1986, dando
origem ao SGML (Standard Generalized Markup Language).
A prpria linguagem HTML (Hypertext Markup Language), base para a criao

de qualquer pgina da Internet, foi criada com base no SGML, sendo seu
surgimento em 1989.
Com a criao da W3C (World Wide Web Consortium), em 1994, as regras para
criao de HTML foram formalizadas, padronizando a codificao das pginas,
mas o simples uso de HTML no cumpria com todas as necessidades da
Internet.
Surgindo em 1996, a sintaxe XML foi publicada como uma recomendao da

W3C, em 1998, sendo revisada em 2000, e tornou-se um padro de grande
utilizao at mesmo na criao de pginas, como no uso de XHTML
(eXtensible Hypertext Markup Language).
A sintaxe XML no uma linguagem especfica, com comandos definidos, e

nem define uma gramtica, mas apenas as regras mnimas de escrita. Entre as
regras de escrita do XML encontram-se:

(figura representativa da sintaxe XML)
Todo elemento tem que apresentar etiqueta de fechamento.

Valores de atributos devem ser colocados entre aspas ou apstrofes.
A nomenclatura de elementos e atributos diferencia maisculas e minsculas.
Os nomes podem conter qualquer caractere alfanumrico ou ideograma,
ponto, hfen e sublinhado, mas no podem comear por ponto, hfen ou
nmero.
No permitido o uso de espaos no nome do elemento ou atributo.
Ns de texto no podem utilizar caracteres reservados, como sinais de menor
e maior.
Os elementos devem estar corretamente aninhados.
Qualquer documento apresenta apenas um elemento raiz.
Atributos no podem ser repetidos para a mesma ocorrncia do elemento.

(Quadro representativo do correto e do incorreto sobre a sintaxe XM)
Documento XML
Todo documento XML pode ser interpretado como uma rvore composta de um
elemento raiz, elementos derivados, ns de texto, alm de atributos para
determinados elementos. Alm destes, encontram-se na estrutura do XML os
seguintes componentes:
Instrues de processamento, utilizadas apenas por processadores especficos

de XML, sendo ignoradas por aqueles que no as utilizam. Uma instruo de
processamento tipicamente presente o prlogo do XML.

Comentrios, os quais seguem a mesma sintaxe do HTML, e so ignorados
pelos diversos processadores de XML.
Sees CDATA, as quais no so interpretadas segundo as regras sintticas

do XML, se comportando como texto corrido.

Entidades, utilizadas para a representao de caracteres especiais, aparecem
em qualquer lugar do XML e so substitudas no processamento do mesmo. So
extremamente teis na substituio de caracteres especiais para os ns de
texto.
Entidades
As entidades seguem a sintaxe &ENTIDADE; podem representar caracteres
especiais ou elementos da tabela ASCII, como pode ser observado a seguir:
(Quadro representativo dos elementos da tabela ASCII)

comum nos arquivos XML haver a necessidade de diferenciar elementos com
nomes iguais, mas que se aplicam a contextos diferenciados, e para tal deve
ser utilizado o ferramental denominado Namespace.
Para o uso de um Namespace utilizado na tag de abertura de um elemento a

sintaxe xmlns:namespace prefix="namespace", onde namespace-prefix
ser o prefixo utilizado para diferenciar os elementos no XML, e Namespace
propriamente dito se refere a uma URI, conforme especificado pela W3C.
Exemplo da W3C
Utilizando o exemplo fornecido pela prpria W3C, considere os dois trechos XML
seguintes:
Fragmento de informao constituinte de uma tabela HTML
Fragmento de informao referente a uma mesa (mobilirio)

Colocando os dois trechos em um mesmo arquivo ocorreria o conflito de nomes
com relao ao elemento table, onde o significado de cada um distinto. Isso
resolvido com a utilizao de Namespace.
Embora o Namespace seja definido a partir de uma URI, os parsers no iro

acessar o endereo especificado na hora de interpretar o XML. Essa URI serve
basicamente para tornar o identificador do Namespace nico.
Outra opo de escrita, inclusive a mais adotada, seria a definio dos

Namespaces no elemento raiz.

Formas gramaticais em XML
Um documento XML bem formado aquele que segue todas as regras de
escrita. Em termos prticos, se no bem formado no XML. No entanto, um
documento bem formado pode no ser til, ou vlido, para determinado
contexto de aplicativo, pois o mesmo certamente exigir um formato de dados
compatvel, segundo uma gramtica especfica, ou domnio do sistema. So
duas as formas para definir gramticas em XML:
DTD
Apresenta uma sintaxe bastante simples, mas no segue o padro do XML.

No permite o uso de namespaces.
No permite a definio de estruturas de dados complexas.
XSD
Apresenta uma sintaxe mais complexa, dentro das regras do XML.

Permite a utilizao de namespaces.
Permite a definio de estruturas de dados complexas.
Formas gramaticais em XML

Exemplo de DTD apresentado pela W3C (http://www.w3schools.com/dtd/):
<?xml version="1.0"?>
<!DOCTYPE note [
<!ELEMENT note (to,from,heading,body)>
<!ELEMENT to (#PCDATA)>
<!ELEMENT from (#PCDATA)>
<!ELEMENT heading (#PCDATA)>
<!ELEMENT body (#PCDATA)>
]>
<note>
<to>Tove</to>
<from>Jani</from>
<heading>Reminder</heading>
<body>Don't forget me this weekend</body>
</note>

A seguir, um exemplo de XSD (XML Schema Datatype) apresentado pela W3C
(http://www.w3schools.com/schema/):
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:element name="note">
<xs:complexType>
<xs:sequence>
<xs:element name="to" type="xs:string"/>
<xs:element name="from" type="xs:string"/>
<xs:element name="heading" type="xs:string"/>
<xs:element name="body" type="xs:string"/>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:schema>
Em termos gerais, devido sua flexibilidade, o uso de XSD foi mais difundido,
sendo utilizado em vrias plataformas tecnolgicas da atualidade, como nos
webservices.
Linguagens de transformao
Outra preocupao com relao aos dados presentes nos arquivos XML, alm
da definio de vocabulrios adequados, a possibilidade de transformar esses
dados para algum outro formato de visualizao ou exportao. Nesse ponto
surgem as linguagens de transformao, como XSLT e XSL-FO, ambas seguindo
a sintaxe XML para efetuar as transformaes nos arquivos XML de origem.
Hoje em dia, com a advento das mais diversas plataformas de acesso web,
como smartphones, tablets e TVs digitais, o conceito de design responsivo tem
sido um elemento muito explorado no mercado. Como a mesma informao
deve ser apresentada de diferentes formas, em diferentes dispositivos, as
linguagens de transformao acabam fornecendo uma tima soluo para

evitar o retrabalho na construo de mltiplas interfaces para o mesmo
software.
XSLT
O uso de XSLT muito comum no controle da aparncia visual de arquivos
XML, quando disponibilizados em navegadores para web, como ocorre para os
recursos de notcias RSS.
Uma estrutura comum nos sites da atualidade composta de linguagem de

dados XML, linguagem de estruturao XHTML ou HTML 5, linguagem de
transformao XSLT e linguagem de formatao CSS, alm das aes da pgina
providas por Java Script e JSON, muitas vezes ainda apoiado em bibliotecas
como JQuery UI. Os dados XML so transformados via XSLT para uma
visualizao XHTML-CSS ou HTML5-CSS.
Considere o arquivo XML a seguir:
Com a utilizao de um arquivo XSL apropriado, como o apresentado a seguir,

possvel controlar sua visualizao no navegador.
XSLT
Os comandos do XSLT normalmente utilizam o prefixo xsl, porm nada
impediria de se utilizar outro prefixo. A tabela seguinte apresenta alguns dos
comandos disponveis na sintaxe do XSLT.

Comando Utilizao Exemplo
Output Define o formato de <xsl:output method="html" version="4.0"

sada encoding="UTF-8"/>
template Define o modelo a ser <xsl:template match="/">

aplicado quando
determinado tipo de
n for encontrado
apply- Aplica um modelo ao <xsl:template match="message">

template elemento corrente ou <h1>
ns filhos do mesmo
<xsl:apply-templates select="*" mode="big"/>
</h1>
</xsl:template>
value-of Retorna o valor do n <xsl:value-of select="title"/>
Variable Declara uma varivel <xsl:variable name="header">

local <tr><th>Element</th><th>Description</th></tr>
</xsl:variable>
copy-of Copia o valor do n <xsl:copy-of select="$header" />
for-each Repete para cada n <xsl:for-each select="catalog/cd">

do conjunto
selecionado
Sort Ordena a sada para <xsl:for-each select="catalog/cd">

um conjunto for-each <xsl:sort select="artist">
If Testa uma condio <xsl:if test="price > 10">

para o elemento <li><xsl:value-of select="title"/></li>
corrente </xsl:if>
choose, Trabalham em <xsl:choose>

when e conjunto, iniciado por <xsl:when test="price > 10">
otherwise choose, e definindo <td bgcolor="#ff00ff">
qual ao executar Preo normal
quando satisfeita a </td>
condio de when, e </xsl:when>
o que fazer quando <xsl:otherwise>
nada for satisfeito <td>Oferta!</td>
</xsl:otherwise>
atravs de otherwise
</xsl:choose>
Uma listagem completa dos comandos do XSLT est disponvel no endereo

<http://www.w3schools.com/xsl/xsl_w3celementref.asp>.

XSL-FO
Quanto ao XSL-FO (XML Stylesheet Language - Formatting Objects), este
destina-se criao de documentos em formatos voltados para plataformas
especficas, como arquivos PDF, por exemplo.
A sintaxe XSL-FO apresenta um conjunto muito rico de opes para

formatao, paginao e tipografia de documentos.
O n raiz da rvore de objetos de formatao deve ser um fo:root. Os filhos

possveis do fo:root so um nico fo:layout-master-set, opcionalmente

fo:declarations e fo:bookmark-tree, e uma sequncia de um ou mais elementos
fo:page-sequence-wrapper e fo:page-sequence. Enquanto fo:layout-master-set
define a geometria e sequenciamento das pginas; os filhos do fo:page-
sequence, que so chamados de fluxos (contidos em fo:flow e fo:static-
content), fornecem o contedo que distribudo nas pginas.
Os comandos anteriores fazem parte do aspecto de paginao e formatao do

XSL-FO, sendo a rvore completa apresentada a seguir.
Tambm so utilizados vrios atributos que permitem justificar o texto ou

alterar a fonte e caracteres (internacionalizao), como font-selection-strategy,
font-weight e country.
Tambm so utilizados vrios atributos que permitem justificar o texto ou

alterar a fonte e caracteres (internacionalizao), como font-selection-strategy,
font-weight e country. Um exemplo de arquivo de transformao XSL-FO
apresentado a seguir.
<?xml version="1.0" encoding="UTF-8"?>
<fo:root xmlns:fo="http://www.w3.org/1999/XSL/Format">
<fo:layout-master-set>
<fo:simple-page-master master-name="HelloWorld">
<fo:region-body/>
</fo:simple-page-master>

</fo:layout-master-set>
<fo:page-sequence master-reference="HelloWorld">
<fo:flow flow-name="xsl-region-body">
<fo:block font-family="Arial" font-size="18pt">
1. Primeiro Exemplo
</fo:block>
<fo:block margin-left="10mm" font-family="Arial" font-size="18pt">
2. Segundo Exemplo
</fo:block>
<fo:block margin-left="10mm" margin-top="20mm" font-family="Times New Roman"

font-size="24pt">
3. Terceiro Exemplo
</fo:block>
</fo:flow>
</fo:page-sequence>
</fo:root>
Normalmente, esse tipo de documento gerado com o uso de XSLT, isso

devido s informaes dinmicas providas via XML, como no pequeno trecho de
cdigo abaixo:
<xsl:template match="/">
<fo:root xmlns:fo="http://www.w3.org/1999/XSL/Format">
<xsl:apply-templates />
</fo:root>
</xsl:template>
Atravs de um aplicativo como o FOP (Formatting Objects Processor),

desenvolvido em Java e hoje conhecido como Apache FOP, possvel a
converso das fontes FO (Formatting Objects) em formatos diversos, entre
eles: PDF, ASCII, PostScript, SVG e RTF.

Outras tecnologias XML
Vrios outros exemplos de uso de XML podem ser encontrados no mercado,
incluindo tecnologias que foram absorvidas pelo HTML 5 na concepo de
pginas segundo o foco da Web 2.0. Algumas dessas tecnologias so
apresentadas a seguir:
SVG (Scalable Vector Graphics), para a construo de grficos vetoriais

em XML;
XMI (XML Metadata Interchange), utilizado para troca de informaes de
metadados entre ferramentas de modelagem UML (Unified Modeling
Language);
MathML, utilizado na representao de modelos matemticos;
SOAP (Simple Object Access Protocol), protocolo de transmisso de
dados utilizado por Web Service;
SMIL (Synchronized Multimedia Integration Language), para a
construo de apresentaes multimdia interativas;
CML (Chemical Markup Language), para a formulao de elementos
qumicos.
Atividade proposta
Como atividade de fixao, crie uma pgina XSLT para apresentar o XML
seguinte no formato visual desejado.

Referncias
Morrison, M. Brownell, D. Boumphrey, F. XML Unleashed, Editora Sams.
1999.
Berglund, A. Extensible Stylesheet Language (XSL) Version 1.1. 2006.

http://www.w3.org/TR/xsl/
Valentine, C. Dykes, L. Tittel, E. Understanding XML Schema, SYBEX, 2001.

http://www.eyrolles.com/Chapitres/9780782140453/chap05.pdf

Exerccios de fixao
Questo 1
"Elemento do XML que no interpretado segundo as regras sintticas do
mesmo, se comportando como texto corrido."
Esta a definio de que componente da sintaxe XML?
a) N de texto
b) Seo CDATA
c) Atributo
d) Comentrio
e) Instruo de Processamento
Questo 2
Uma forma de definir gramticas XML com sintaxe bastante simples, porm
sem uso de namespaces e sem a possibilidade de trabalhar com estruturas de
dados complexas, seria atravs de:
a) CSS
b) XSD
c) XSL
d) DTD
e) RPC
Questo 3
Quando h, nos arquivos XML, a necessidade de diferenciar elementos com
nomes iguais, mas que se aplicam a contextos diferenciados, qual componente
dever ser utilizado?
a) Entidade
b) Comentrio
c) N de Texto
d) Atributo
e) NameSpace

Questo 4
As entidades seguem a sintaxe &ENTIDADE; e podem representar caracteres
especiais ou elementos da tabela ASCII. Qual das entidades abaixo no est
corretamente descrita em termos do que representa?
a) A significa "espao"
b) < significa "menor que"
c) > significa "maior que"
d) & significa "&"
e) ' significa "apstrofe"
Questo 5
Uma forma de definir gramticas XML com uso da prpria sintaxe XML e
namespaces, e com a possibilidade de trabalhar com estruturas de dados
complexas, seria atravs de:
a) CSS
b) XSD
c) XSL
d) DTD
e) RPC
Questo 6
Qual o comando do XSL utilizado de forma a repetir um determinado trecho
para cada n do conjunto correntemente selecionado?
a) for-each
b) select
c) if
d) choose
e) when
Questo 7
Qual o nome da tecnologia utilizada para a construo de grficos vetoriais em
XML?

a) MathML
b) CML
c) XMI
d) SMIL
e) SVG
Questo 8
Tecnologia preparada para a gerao de arquivos binrios, destinada criao
de documentos em formatos voltados para plataformas especficas, como PDF:
a) XSLT
b) CML
c) XSL-FO
d) MathML
e) SVG
Questo 9
Para que serve o comando template no XSL?
a) Define o formato da sada.
b) Define o modelo a ser utilizado para determinado tipo de n.
c) Aplica um modelo ao elemento corrente ou filhos do mesmo.
d) Retorna o valor do n.
e) Declara uma varivel.
Questo 10
Os elementos que efetivamente fornecem o contedo a ser distribudos nas
pginas, segundo o XSL-FO seriam:
a) fo:root e fo:layout-master-set
b) fo:page-sequence e fo:bookmark-tree
c) fo:layout-master-set e fo:declarations
d) fo:root e fo:sequence
e) fo:flow e fo:static-content

Aula 5
Exerccios de fixao
Questo 1 - B
Justificativa: Apenas a seo CDATA permite elementos como sinal de maior e
de menor, sem que estes sejam interpretados de alguma forma pelos parsers, o
que permite, por exemplo, a incluso de cdigo-fonte em alguma linguagem
dentro de um arquivo XML.
Questo 2 - D
Justificativa: So duas as formas de definir gramticas: DTD e XSD. Quanto ao
texto, este se refere ao DTD, pois o mesmo apresenta como caractersticas:
Sintaxe bastante simples, mas no no padro do XML.
No permite o uso de namespaces.
No permite a definio de estruturas de dados complexas.
Questo 3 - E
Justificativa: Devem ser utilizados namespaces sempre que duas ou mais
gramticas se cruzam dentro do mesmo arquivo XML. Entidades so utilizadas
para caracteres especiais, e os demais so componentes estruturais comuns de
qualquer XML.
Questo 4 - A
Justificativa: O cdigo ASCII 65, assinalado pela entidade A
corresponde ao caractere "A" (letra a maiscula). Os demais esto corretos.
Questo 5 - B
Justificativa: So duas as formas de definir gramticas: DTD e XSD. Quanto ao
texto, este se refere ao XSD, pois o mesmo apresenta como caractersticas:
Sintaxe mais complexa, dentro das regras do XML.
Permite a utilizao de namespaces.

Permite a definio de estruturas de dados complexas.
Questo 6 - A
Justificativa: O comando que causa uma repetio para cada elemento do
conjunto o for-each. Com relao ao select, este determina o que ser
selecionado para o conjunto, enquanto os demais elementos (if, choose e
when) servem para desvios condicionais.
Questo 7 - E
Justificativa: SVG (Scalable Vector Graphics) utilizado para a construo de
grficos vetoriais em XML, sendo amplamente utilizado no HTML 5. Quanto aos
demais:
- XMI (XML Metadata Interchange), utilizado para troca de informaes de
metadados entre ferramentas de modelagem UML (Unified Modeling
Language).
- MathML, utilizado na representao de modelos matemticos.
- SMIL (Synchronized Multimedia Integration Language), para a construo de
apresentaes multimdia interativas.
- CML (Chemical Markup Language), para a formulao de elementos qumicos.
Questo 8 - C
Justificativa: A tecnologia XSL-FO (XML Stylesheet Language - Formatting
Objects), este destina-se criao de documentos em formatos voltados para
plataformas especficas, como arquivos PDF, por exemplo. Diferencia-se do
XSLT padro, pois este ltimo faz transformaes em modo texto. Quanto ao
SVG, o MathML e o CML, estas so tecnologias XML para domnios especficos,
sendo respectivamente: grficos, matemtica e qumica.
Questo 9 - B
Justificativa: Para definir o formato de sada utilizado o comando output;
value-of retorna o valor do n selecionado; variable declara uma varivel local;
apply-template aplica um modelo ao elemento corrente e filhos do mesmo.

Quando utilizamos template estamos definindo o modelo que ser aplicado
(com apply-template) a determinado tipo de n for encontrado em um conjunto
selecionado.
Questo 10 - E
Justificativa: O n raiz da rvore de objetos de formatao deve ser um fo:root.
Os filhos possveis do fo:root so um nico fo:layout-master-set, opcionalmente
fo:declarations e fo:bookmark-tree, e uma seqncia de um ou mais elementos
fo:page-sequence-wrapper e fo:page-sequence. Enquanto fo:layout-master-set
define a geometria e sequenciamento das pginas; os filhos do fo:page-
sequence, que so chamados de fluxos (contidos em fo:flow e fo:static-
content), fornecem o contedo que distribudo nas pginas.

Introduo
Com a popularizao da Internet e aumento do comrcio eletrnico, torna-se
comum a necessidade de integrao entre sistemas de diferentes plataformas,
muitas vezes visando s transaes financeiras e logstica.
Nesse novo cenrio, o uso de XML em plataformas de servios estilo RPC,

inicialmente utilizando solues XML-RPC e posteriormente Web Services,
apresenta-se como uma grande soluo de integrao, garantindo a
interoperabilidade com acoplamento extremamente baixo.
Com esse tipo de soluo, novos horizontes se abriram, e sistemas voltados

para o comrcio entre empresas passaram a definir o conceito de B2B,
posteriormente sendo expandido para o comrcio direto com o consumidor,
denominado B2C.
Objetivo:
1. Compreender o XML-RPC e o SOAP;
2. Implementar a interoperabilidade via Web Services.

Contedo
XML-RPC
Uma soluo simples para a criao de aplicativos distribudos interoperveis
o uso de XML-RPC, opo de arquitetura na qual as chamadas e respostas RPC
seguem o formato XML para os dados de envio e recepo. Caractersticas do
XML-RPC:
Criado para ser to simples quanto possvel, definindo as interfaces de

chamadas remotas, mas no implementando os mtodos ouvintes nos
servidores;
Utiliza um vocabulrio baseado em XML;
Tem uma quantidade limitada de comandos (tags) para descrever
funes, tipos de parmetros e tipos de retorno;
Utiliza o protocolo HTTP para o transporte na Internet;
Voltado para a comunicao computador a computador, e no de
usurio a computador;
O uso do protocolo HTTP e sintaxe XML permite sua passagem livre por
firewalls;
Vrias implementaes de servidores e clientes XML-RPC podem ser
encontradas.
Um exemplo de chamada e resposta XML-RPC pode ser observado a seguir:
(imagem representativa de chamada e resposta XML-RPC)

Entre os elementos da sintaxe XML-RPC encontram-se:
methodCall:
Chamada de um mtodo remoto a partir do cliente.
mehodResponse:
Define a resposta enviada pelo servidor ao cliente.
methodName:
Nome do mtodo chamado no servidor.
Params:
Setor de parmetros da chamada ou resposta.
Param:
Define um parmetro, devendo conter seu valor e tipo.
Os tipos aceitos no XML-RPC podem ser observados na seguinte tabela:
Alm desses tipos, podem ser criadas estruturas mais complexas com o uso de
struct, como no exemplo a seguir:

Cada elemento de struct deve conter nome e valor, onde o valor pode ser outro
struct, aplicado de forma recursiva.
Tambm podem ser criadas colees com o uso de array, podendo ter como
elementos dessas colees elementos struct, os quais podem tambm utilizar
array nos seus valores (value).
Logo, a combinao de estruturas complexas e colees (ou vetores), de forma

dinmica e recursiva, permite expressar tipos de dados diversos com grande
facilidade, o que viabiliza a implementao de clientes e servidores nas mais
diversas plataformas.
importante observar tambm que a chamada dos procedimentos est sujeita

a falhas, e uma resposta indicando que algo errado ocorreu utilizar o elemento
fault. Esse elemento pode ser definido como uma estrutura composta do cdigo
do erro (faultCode) e mensagem do erro (faultString).

Implementao em Java
Em termos de Java, uma biblioteca muito interessante para trabalhar com XML-
RPC disponibilizada pelo Apache, sendo seu uso baseado no mapeamento de
um simples Servlet, um arquivo de propriedades e uma classe de negcios bem
independente.

Com esses poucos componentes criada a parte servidora do XML-RPC, sendo
o cliente to simples quanto, como pode ser observado a seguir.
SOAP
Em termos gerais, o SOAP (Simple Object Access Protocol) define um protocolo
de comunicao remota estilo RPC com uso de XML, extensvel e amplamente
utilizado na comunicao com Web Services. Suas caractersticas principais so:
1: Objetivar a comunicao entre aplicativos;

2: Definir um formato padro para envio de mensagens;
3: Permitir a comunicao na Internet de forma transparente aos firewalls;
4: Ser independente de plataforma e de linguagem de programao;
5: Utilizar sintaxe XML, bastante simples e extensvel;
6: uma recomendao da W3C desde o dia 24 de junho de 2003.
A sintaxe do SOAP segue algumas regras importantes:

A mensagem criada com uso da sintaxe XML;
Precisa utilizar os namespaces soap-envelop e soap-encoding;

No pode ser utilizado um DTD;
No so permitidas instrues de processamento XML.
O esqueleto de uma mensagem SOAP apresentado a seguir:
A seo Header opcional e permite a incluso de informaes especficas do

aplicativo, como autenticao e pagamento, por exemplo. Se essa seo estiver
presente dever constar como o primeiro elemento filho do envelope SOAP.
A seo Header opcional e permite a incluso de informaes especficas do

aplicativo, como autenticao e pagamento, por exemplo. Se essa seo estiver
presente dever constar como o primeiro elemento filho do envelope SOAP.
O elemento Body apresenta a mensagem em si, definindo chamada ou resposta

de um servio solicitado.
Os elementos filhos de Body devem ter o namespace qualificado, como no

exemplo seguinte com a chamada e a resposta.
<soap:Envelope
xmlns:soap="http://www.w3.org/2001/12/soap-envelope"
soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding">
<soap:Body xmlns:m="http://www.example.org/stock">
<m:GetStockPrice>
<m:StockName>IBM</m:StockName>
</m:GetStockPrice>
</soap:Body>
</soap:Envelope>
<soap:Envelope
xmlns:soap="http://www.w3.org/2001/12/soap-envelope"
soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding">

<soap:Body xmlns:m="http://www.example.org/stock">
<m:GetStockPriceResponse>
<m:Price>34.5</m:Price>
</m:GetStockPriceResponse>
</soap:Body>
</soap:Envelope>
A seo Fault opcional e serve para indicar mensagens de erro. Quando

presente na mensagem, Fault deve se apresentar como um elemento filho de
Body, e permite apenas uma ocorrncia nessa mensagem.
Os subelementos de Fault so apresentados na tabela a seguir.
Subelemento Significado
<faultcode> Cdigo do erro ocorrido
<faultstring> Mensagem do erro
<faultactor> Informaes acerca do responsvel pela falha
<detail> Engloba informaes especficas do aplicativo referentes ao
erro.

Web Services
O conceito de servios no novidade em termos de programao, tratando de
componentes independentes de software que podem ser acionados para
realizar determinadas tarefas, permitindo atravs de seu conjunto realizar aes
maiores segundo uma ordem de chamada definida pelo aplicativo solicitante.
Em termos de Internet, os tipos de servio mais difundidos so Web Services,
os quais podem ser classificados em dois tipos distintos:
SOAP Web Services, os quais permitem grande interoperabilidade com o uso do

protocolo SOAP.
RESTful Web Services, onde utilizado REST (REpresentational State Transfer),

e as mensagens podem utilizar sintaxe XML ou JSON (Java Script Object
Notation).
A grande diferena funcional entre o SOAP e o REST a de que, enquanto o

SOAP foca as chamadas de mtodos remotos, o REST trabalha com envio e
recepo de objetos ou recursos.
Vrias bibliotecas, como JQuery, apresentam maior facilidade em lidar com

REST, j que uma caracterstica deste justamente a simplicidade da
transferncia de informaes, sem o uso de grande formalismo, o que viabiliza
que a resposta seja expressa diretamente em JSON, no entanto, o formalismo
das mensagens SOAP permite sua utilizao facilitada em grandes ferramentas
corporativas.
SOAP Web Services

Alm do protocolo SOAP, utilizado na comunicao entre aplicativos para Web
Services desse tipo, ser necessrio tambm um descritor de servios, o WSDL
(Web Service Description Language).

atravs desse WSDL que diversas IDEs, como Visual Studio e NetBeans,
conseguem criar o cliente com as chamadas corretas, deixando o programador
com a sensao de que est fazendo uma simples chamada local, e sem
envolver nenhum esforo para o mesmo na criao dos stubs de comunicao.
Um documento WSDL define os servios como colees de endpoints ou portas.
Em WSDL, a definio abstrata de endpoints e mensagens independente de
sua implantao na rede ou das converses do formato de dados. Isso permite
a reutilizao de definies abstratas: mensagens, que so descries abstratas
dos dados que esto sendo trocados, e os tipos de portas, que so colees
abstratas de operaes.
As especificaes do protocolo e formato de dados concretos para um tipo de

porta em particular constitui um vinculativo reutilizvel. Uma porta definida
atravs da associao de um endereo de rede com um vnculo reutilizvel, e
um conjunto de portas de definir um servio. Feitas essas consideraes, um
documento WSDL usa os seguintes elementos na definio de servios de rede:
Types - Um recipiente para definies de tipo de dados usando algum

tipo de gramtica (como XSD).
Message - Uma definio abstrata do formato de dados da
comunicao.
Operation - Uma descrio abstrata de uma ao suportada pelo
servio.
PortType - Um conjunto abstrato de operaes apoiadas por um ou
mais endpoints.
Binding - Um protocolo concreto e especificao do formato de dados
para um tipo de porta (PortType) particular.
Port - Um endpoint simples, definido como uma combinao de um
binding e um endereo de rede.
Service - Uma coleo de endpoints relacionados.

UDDI
Opcionalmente, esses Web Services podem ser cadastrados em um sistema
para catalogao de servios denominado UDDI (Universal Discovery and
Description Integration), o qual equivale, na prtica, a um servio de nomes e
diretrios.
A principal funo do UDDI retornar a URL do WSDL de um determinado

servio, aps uma busca feita nos prprios registros desse catlogo, tendo
como perfis de pesquisa:
White Pages, referindo-se busca de servios pelo nome;
Yellow Pages, tratando da busca por assunto;
Green Pages, baseado em caractersticas tnicas.
Finalmente, feita uma comparao no quadro seguinte entre as diversas

tecnologias de processamento distribudas comumente utilizadas no mercado
em termos de protocolo, descritor de chamadas e servio de nomes e
diretrios.
Para os Web Services do tipo RESTful utilizado um descritor de servios

denominado WADL (Web Application Description Language).
Em termos gerais, os RESTful Web Services no mantinham uma preocupao

com relao ao registro, como o uso de UDDI para SOAP Web Services; no
entanto, as verses atuais do UDDI j incorporam elementos de busca para
servios REST, e o jUDDI permite que os registros sejam adicionados com
sintaxe JSON.

A interoperabilidade atravs de Web Services garantida pelo uso de
protocolos modo texto de larga aceitao, como SOAP, e a presena de
descritores de servio WSDL para facilitar a criao dos stubs, permitindo a
plena integrao entre diferentes tecnologias e alto nvel de reuso dos servios
e acoplamento extremamente baixo.
Criao de SOAP Web Services em Java

A plataforma JEE5 trouxe grandes facilitadores, inclusive para a escrita de Web
Services, pois ao contrrio de diversos arquivos de configurao XML, hoje
trabalhamos com simples cdigo anotado.
As anotaes utilizadas so:
@WebService define a classe como um servio na Web;

@WebMethod define um mtodo para esse servio;
@WebParam utilizado para definir parmetros de chamada de um
determinado mtodo do Web Service.
Baseado nessas anotaes, o servidor (GlassFish, por exemplo) implementa

toda a infraestrutura para disponibilizao do servio, alm de gerar a WSDL do
mesmo, bem como o XSD (XML Schema), se fazer necessrio.

Criao de Cliente dotNet
Como exemplo de interoperabilidade, pode ser criado um cliente dotNet a partir
da WSDL do Web Service.
A tela seguinte mostra a opo que deve ser utilizada na criao do cdigo
necessrio para a comunicao de forma automatizada.
Aps adicionar a referncia ao servio, este pode ser invocado de forma muito
simples a partir do cdigo na linguagem escolhida dentro da plataforma dotNet,
como pode ser observado a seguir, com uso da linguagem C#.

fcil observar, partindo desse exemplo, a grande facilidade com que as duas
plataformas podem interagir via Web Services, demonstrando de forma simples
como esse tipo de servio garante a interoperabilidade.
Sistemas B2B e B2C

Atualmente, os termos B2B e B2C so amplamente utilizados no mercado, mas
o que realmente representam?
B2B (Business to Business) a sigla utilizada no comrcio eletrnico para

definir transaes comerciais entre empresas. Em outras palavras, um
ambiente onde uma empresa comercializa seus produtos para outras empresas.
A natureza dessa operao pode ser revenda, transformao ou consumo.
B2C (Business to Consumer) a sigla que define a transao comercial

entre empresa e consumidor final atravs de uma plataforma de e-commerce. A
natureza dessa operao tende a ser apenas de consumo.
Os Web Services representam um passo frente para permitir a colaborao

entre vrias entidades na Web e na superao dos problemas de
interoperabilidade que podem aparecer. Parceiros B2B podem se beneficiar ao
permitir que as entidades de negcios exponham suas interfaces de modo
simples e interopervel.
Sistemas de informao baseados em uma arquitetura orientada a servios que

so capazes de integrar diferentes funcionalidades e oferecer um modelo de
componente virtual que abstrai da peculiaridade de implementaes especficas
parecem ser uma soluo muito atraente.
O ambiente de execuo de Web Services apoia B2B comum e cenrios B2C, na

qualidade de um sistema de informao que representa o ponto central de uma
arquitetura de hub-and-spoke. Se dois parceiros desejam se comunicar, eles

simplesmente resumem suas funcionalidades via Web Services, no
diretamente um para o outro.
feita uma distino clara entre a interface e a implementao de um servio,

o que permite o registro, descoberta, composio e execuo sem o
conhecimento da localizao da sua aplicao e tecnologia de implementao.
Alm disso, essa distino apoia a definio semntica de um servio, mesmo
quando a sua aplicao no necessariamente baseada em tecnologia
semntica, mas talvez em um sistema legado.
Em ambientes onde existe a necessidade de comunicao assncrona entre

empresas, como no modelo bancrio, tambm comum o uso de mensagerias
interfaceando os sistemas de ambas as empresas via mensagens.
Atividade proposta
Com o uso do NetBeans e servidor GlassFish, implemente em Java um Web
Service que efetue as quatro operaes matemticas bsicas: soma, subtrao,
multiplicao e diviso.
Utilize a opo "Testar Web Service disponvel a partir do NetBeans com o uso
deste servidor especfico, e teste as funcionalidades do servio criado.

Referncias
Laurent, S. Johnston, J. Dumbill, E. Programming Web Services with XML-
RPC. Editora OReilly, 2001.
Kidd, E. XML-RPC HOWTO, Source Builders. 2001.

http://www.tldp.org/HOWTO/pdf/XML-RPC-HOWTO.pdf
Richardson, L. Ruby, S. RESTful Web Services. Editora OReilly, 2007.
Englander, R. Java and SOAP. Editora OReilly, 2002.

Saudate, A. SOA aplicado: Integrando com web services e alm. Editora Casa
do Cdigo, 2012.

Exerccios de fixao
Questo 1
Qual das opes abaixo NO uma caracterstica do XML-RPC?
a) Criado para ser to simples quanto possvel, definindo as interfaces de
chamadas remotas, mas no implementando os mtodos ouvintes nos
servidores.
b) Utiliza um vocabulrio baseado em JSON.
c) Tem uma quantidade limitada de comandos (tags) para descrever funes,
tipos de parmetros e tipos de retorno.
d) Utiliza o HTTP para o transporte na Internet.
e) Voltado para a comunicao computador a computador, e no de usurio a
computador.
Questo 2
Em termos de XML-RPC, quando ocorre um erro no atendimento solicitao, a
mensagem referente a este erro ser retornada em que elemento da resposta?
a) params
b) faultCode
c) faultString
d) param
e) methodName
Questo 3
Com relao sintaxe do SOAP, qual das opes est INCORRETA?
a) A mensagem criada com uso de XML.
b) Precisa do namespace soap-envelop.
c) Precisa do namespace soap-encoding.
d) Pode ser utilizado um DTD.
e) No so permitidas instrues de processamento XML.

Questo 4
"Para o SOAP a seo _________ opcional, e permite a incluso de
informaes especficas do aplicativo, como autenticao e pagamento, por
exemplo. Se esta seo estiver presente dever constar como o primeiro
elemento filho do envelope."
Qual opo preenche corretamente a lacuna?
a) Body
b) Footer
c) Fault
d) Header
e) Tail
Questo 5
Considere as afirmativas abaixo, com relao ao SOAP:
I - Objetiva a comunicao entre o servidor e o usurio final.
II Permite a comunicao na Internet de forma transparente aos firewalls.
III Utiliza sintaxe JSON.
IV independente de plataforma e de linguagem de programao.
Qual a opo que indica a quantidade de afirmativas corretas?
a) As quatro esto corretas.
b) Apenas trs esto corretas.
c) Apenas duas esto corretas.
d) Apenas uma est correta.
e) Nenhuma das afirmativas est correta.
Questo 6
Para Web Services SOAP utilizado um descritor de servios denominado:
a) WSDL
b) UDDI
c) XML
d) SOAP
e) REST

Questo 7
Para definir um Web Service em linguagem Java atravs de anotaes, a classe
deve ser anotada com _________, cada mtodo que precise ser exposto como
servio deve ser anotado com __________, e cada parmetro presente em
cada um desses mtodos deve ser anotado com _________.
Qual opo preenche corretamente as lacunas?
a) @Stateless, @EJB e @Servlet
b) @Stateless, @EJB e @MessageDriven
c) @WebParam, @WebMethod e @WebService
d) @Override, @Remote e @Local
e) @WebService, @WebMethod e @WebParam
Questo 8
Um componente de grande relevncia nos ambientes de computao distribuda
o sistema de registro, normalmente um servio de nomes e diretrios. Quais
so, respectivamente, os sistemas de registro para RMI-IIOP, CORBA e Web
Services?
a) RMI Registry, COS Naming e UDDI.
b) JNDI, COS Naming e UDDI.
c) WSDL, UDDI e SOAP.
d) JNDI, COS Naming e WSDL.
e) WSDL, CORBA IDL e RMI Registry.
Questo 9
Considerando-se os documentos WSDL, qual elemento relacionado a "um
conjunto abstrato de operaes apoiados por um ou mais endpoints"?
a) Message
b) Types
c) Binding
d) PortType
e) Service

Questo 10
Qual o tipo de Web Service que trabalha com envio e recepo de objetos, e
permite uso tanto de XML quanto JSON?
a) SOAP
b) WADL
c) WSDL
d) UDDI
e) RESTful

Aula 6
Exerccios de fixao
Questo 1 - B
Justificativa: A tecnologia XML-RPC utiliza um vocabulrio baseado em XML. As
demais opes esto corretas.
Questo 2 - C
Justificativa: A chamada dos procedimentos est sujeita a falhas, e uma
resposta indicando que algo errado ocorreu utilizar o elemento fault. Este
elemento pode ser definido como uma estrutura composta do cdigo do erro
(faultCode) e mensagem do erro (faultString).
Questo 3 - D
Justificativa: A sintaxe do SOAP no permite o uso de DTD. As demais opes
esto corretas.
Questo 4 - D
Justificativa: A opo Header preenche corretamente a lacuna. A seo Body
est relacionada chamada e resposta do servio, e a seo Fault refere-se
ocorrncia de um erro qualquer. Quanto a Footer e Tail, estas opes no
existem no SOAP.
Questo 5 - C
Justificativa: As afirmativas II e IV esto corretas, no entanto a I est incorreta,
pois o foco do SOAP a comunicao entre aplicativos, e a III est incorreta
pelo fato de ser utilizado XML, e no JSON.
Questo 6 - A
Justificativa: Alm do protocolo SOAP, utilizado na comunicao entre
aplicativos para Web Services deste tipo, ser necessrio tambm um descritor

de servios, o WSDL (Web Service Description Language). atravs deste
WSDL que diversas IDEs, como Visual Studio e NetBeans, conseguem criar o
cliente com as chamadas corretas, deixando o programador com a sensao de
que est fazendo uma simples chamada local, e sem envolver nenhum esforo
para o mesmo na criao dos stubs de comunicao.
Questo 7 - E
Justificativa: As anotaes utilizadas para definir o Web Service so:
@WebService define a classe como um servio na Web.
@WebMethod define um mtodo para este servio.
@WebParam utilizado para definir parmetros de chamada de um
determinado mtodo do Web Service.
Questo 8 - B
Justificativa: O quadro seguinte mostra uma sntese das diversas plataformas e
componentes.
Segundo o quadro, o RMI-IIOP utiliza JNDI, CORBA utiliza COS Naming e os

Web Services trabalham com UDDI.
Questo 9 - D
Justificativa: Um documento WSDL usa os seguintes elementos na definio de
servios de rede:
- Types - Um recipiente para definies de tipo de dados usando algum tipo de
gramtica (como XSD).
- Message - Uma definio abstrata do formato de dados da comunicao.
- Operation - Uma descrio abstrata de uma ao suportada pelo servio.

- PortType - Um conjunto abstrato de operaes apoiadas por um ou mais
endpoints.
- Binding - Um protocolo concreto e especificao do formato de dados para um
tipo de porta (PortType) particular.
- Port - Um endpoint simples, definido como uma combinao de um binding e
um endereo de rede.
- Service - uma coleo de endpoints relacionados.
Questo 10 - E
Justificativa: Para RESTful Web Services, onde REST significa REpresentational
State Transfer), as mensagens podem utilizar sintaxe XML ou JSON (Java Script
Object Notation). Diferentemente do SOAP, que foca as chamadas de mtodos
remotos, o REST trabalha com envio e recepo de objetos ou recursos.
Quanto s demais opes, WADL descreve um Web Service REST, enquanto
WSDL descreve um do tipo SOAP, e UDDI o servio de registro e localizao
de Web Services.

Introduo
Como soluo para a gesto de ambientes heterogneos e reuso de
componentes j existentes, surge uma nova filosofia em termos arquiteturais
para a criao de sistemas corporativos.
As arquiteturas orientadas a servios tratam as diferentes tecnologias

envolvidas, sejam elas novas ou antigas, a exemplo dos mainframes, como
simples componentes que devero expor ou consumir servios, sempre
intermediados pelo ferramental provido na arquitetura.
Objetivo:
1. Compreender os princpios fundamentais de uma arquitetura orientada a
servios;
2. Analisar as possibilidades de integrao entre plataformas e uso de
tecnologias legadas.

Contedo
Princpios do SOA
O que ?
As arquiteturas orientadas a servios (SOA, do ingls Service Oriented
Architecture) so a evoluo natural da concepo de sistemas, visando o reuso
e a interoperabilidade.
Como funciona?
Um servio definido como uma funo independente, sem estado (stateless),
que aceita uma ou mais requisies e devolve uma ou mais respostas por meio
de uma interface padronizada e bem-definida.
E tambm
Servios podem tambm realizar partes discretas de um processo, tal como
editar ou processar uma transao, e no devem depender do estado de outras
funes ou processos.
A tecnologia utilizada para prover o servio, tal como uma linguagem de

programao no pode fazer parte da definio do mesmo.
Incialmente os sistemas eram monolticos, passando a trabalhar com

metodologias estruturadas ou orientadas a objetos. Com o uso de redes,
passamos a ter sistemas cliente-servidor, os quais evoluram para sistemas
divididos em camadas, como na arquitetura MVC (Model, View e Control). Com
as necessidades transacionais e de distribuio de processamento, torna-se
comum o uso de objetos distribudos e posteriormente sistemas baseados em
componentes corporativos. Finalmente surgem os servios orientados a
componentes, definindo a base do SOA.
Uma arquitetura baseada em componentes considera a diviso das

funcionalidades do todo em funes menores, encapsuladas em componentes,

os quais podem estar em diferentes locais fsicos, quando tratamos de objetos
distribudos.
A grande vantagem dos componentes o fcil reuso e sua substituio, o que

simplifica a manuteno, caracterizando os requisitos de negcio 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 servios mais comumente adotado
nessa arquitetura. Outros elementos, como o ESB (Enterprise Service Bus) e
ferramentas de orquestrao de servios devem estar presentes para viabilizar
esse tipo de arquitetura.
Um termo muito utilizado em termos de programao "acoplamento ", que

trata do nvel de interdependncia entre os mdulos de um sistema. Uma das
caractersticas do SOA justamente o baixo acoplamento, e o mdulo
considerado coeso quando possui uma atividade bem-definida e um baixo
acoplamento.
Um ambiente SOA deve ser independente de plataforma, conferindo a

caracterstica de neutralidade, e precisa ser baseado em padres e apresentar
contratos de uso formais entre os pontos de uso, o que determina obrigaes
especficas entre produtor e consumidor.
Tambm deve ocorrer um grande nvel de abstrao do servio frente a sua

implementao, e apresentar meios de publicao popularizados, apresentando
sempre a especificao das funcionalidades da interface do servio, sem
demonstrar sua implementao. Da mesma forma, um servio deve ser
consumvel de forma prtica, com ferramentas para descoberta e uso
automatizado.

Qualquer funcionalidade do ambiente deve ser relevante, apresentando funes
em uma granularidade reconhecida como significativa, bem como deve garantir
o reuso do servio sem a necessidade de cpia ou adaptaes.
Pode-se considerar o SOA como um paradigma arquitetural no qual

componentes de aplicaes so distribudos, combinados e consumidos atravs
de interfaces de servios. Logo, no trata de uma tecnologia especfica, e sim
de uma metodologia de projeto e organizao da infraestrutura de
funcionalidades em um ambiente corporativo.
Conceitos de arquitetura orientada a servio

Alguns conceitos devem ser necessariamente implementados para viabilizar
uma arquitetura orientada a servios:
Servios
Trata de funes disponibilizadas por um sistema computacional para outros
sistemas. Deve funcionar de forma independente de outros servios e possuir
interface bem-definida, como no caso dos Web Services.
Descritores
Refere-se ao conjunto de parmetros, regras e polticas envolvidas na chamada
do servio, tendo como exemplo o WSDL.
Publicao e Descoberta
A publicao de um servio trata de sua divulgao, enquanto a descoberta
ocorre quando um futuro consumidor desse servio obtm informaes acerca
da existncia do mesmo. Podem ser utilizados repositrios de registros ou
servios de nomes e diretrios.
Exemplos de repositrios so o OASIS ebXML e UDDI, tratando de ferramentais

onde podem ser armazenados e gerenciados artefatos como XML Schemas e
WSDL.

Um servio de nomes e diretrios prov informaes acerca das ligaes com
determinados componentes. Nele so encontradas informaes acerca da
localizao de descritores e objetos, como no caso do JNDI.
Modelo de Dados
Trata da especificao de um modelo de dados associado, como W3Cs WSDL,
trazendo um vocabulrio comum ao ambiente, o que permite a serializao de
parmetros em plataformas distintas, garantindo a interoperabilidade.
Contratos de Servio
Os servios devem ser utilizados segundo contratos bem-definidos, os quais
devem ser aceitos pelo seu consumidor.
O que podemos observar que a arquitetura orientada a servios nada mais

que a evoluo natural da arquitetura de sistemas tradicional para solucionar as
necessidades de desenvolvimento e capacidade de adaptao s novas
demandas, dentro de um mercado cada vez mais exigente em termos de
qualidade e agilidade.
Governana e Segurana
Outra caracterstica desejvel em arquiteturas desse tipo a possibilidade de
governana. Esse termo refere-se gesto de polticas e processos necessrios
boa utilizao da arquitetura, com a definio de papis e determinao de
objetivos claros.

Com relao aos papis, estes se referem s diversas pessoas envolvidas com o
sistema, particularmente aquelas que assumem tarefas da gesto de tecnologia
da informao e projetos.
As polticas definem regras claras, que devero ser seguidas por pessoas com
diferentes papis, para que os objetivos primordiais do uso da arquitetura
sejam alcanados.
Os processos definidos para garantir a governana do SOA envolvem:

Definio de polticas de uso da arquitetura;
Estabelecimento de metodologias de comunicao;
Estratgias de treinamento adequadas;
Implantao e acompanhamento de servios.
Muitas empresas definem os servios de forma avulsa, integrando-os sem

trabalhar com princpios de governana, o que pode se tornar bastante
complicado medida que os projetos surgem e a necessidade de controle fica
mais clara.
Uma boa soluo de governana deve compreender o gerenciamento de todo o

ciclo de vida dos diversos ativos, sejam estes servios, modelos, servidores, ou
outros, e dever, portanto, englobar todos os passos da criao at a remoo
de um servio, incluindo anlise, modelagem, codificao, testes e implantao.
Telas sobre governana

As figuras seguintes mostram duas telas voltadas para governana oferecidas
por uma das ferramentas Oracle voltadas para o tema: Oracle Enterprise
Manager SOA Management Pack Enterprise Edition.
possvel observar, na primeira, o acesso a dados histricos em um painel de

instrumentos com anlises estatsticas, enquanto a segunda demonstra a
gesto de transaes de negcios atravs da ferramenta.

Aspectos de segurana
Finalmente, os aspectos de segurana no podem ser deixados de lado em uma
arquitetura orientada a servios, e no basta pensar apenas em padres de
segurana para Web Services, como WS-Trust, WS-Security e SAML, mas sim

tratar de polticas de segurana que envolvam todos os componentes da
arquitetura.
Entre os elementos de segurana, podemos citar a autenticao e autorizao,

referentes identificao de um elemento (usurio, processo, componente,
entre outros) e a permisso do acesso a recursos por parte do mesmo.
Quanto s informaes, comum o uso de assinatura digital para garantir a

autenticidade e a confidencialidade. Essas informaes devem ser protegidas no
trnsito (transporte) entre o servio e seu consumidor, sendo comum o uso de
protocolos como SSL (Secure Socket Layer) e TLS (Transport Layer Security).
necessria uma gesto da base de dados de usurios, bem como

implementao de Polticas de Segurana, as quais denotam um conjunto de
regras de negcio que estabelecem o comportamento de um sistema de
computao, podendo envolver os mais diversos participantes.
Outro elemento importante a rastreabilidade, ou seja, a possibilidade de

efetuar o acompanhamento dos eventos histricos de determinado usurio, de
modo a apurar a responsabilidade sobre qualquer tipo de ao na utilizao da
arquitetura.
Todo esse conjunto de aspectos de segurana acabam levando necessidade

de sistemas gestores bastante complexos. Como exemplo, a figura seguinte
mostra a gesto de segurana do Oracle Fusion Middleware, o qual utiliza
muitas ferramentas do Java como o Java Key Store e o JAAS (Java
Authentication and Authorization Service).

Integrao e uso de tecnologias legadas
Sistema legado o termo utilizado em referncia aos sistemas computacionais
de uma organizao que, apesar de serem bastante antigos, fornecem servios
essenciais, sendo comum a utilizao de bancos de dados obsoletos.
Normalmente, so aplicaes complexas, de difcil manuteno, e que pelo grau
de criticidade e custo para modernizao continuam ativas.
Devido falta de documentao e sada dos desenvolvedores inicialmente

envolvidos nos projetos, os sistemas legados podem apresentar problemas
como:
Dificuldade para a compreenso das regras de negcio originalmente

implementadas;
Desconhecimento dos requisitos que levaram a tomar determinadas decises;
Incoerncia na estruturao dos mdulos de cdigo;
Miscelnea de estilos de programao;

Obsolescncia das ferramentas de desenvolvimento e bases de dados;
Indisponibilidade de mo de obra qualificada;
Impossibilidade de reaproveitamento dos equipamentos nos quais so
executados; para execuo de softwares mais atuais.
Todos esses fatores encarecem a manuteno, e como a substituio do

sistema pode ser invivel, o comum que as empresas procedam
modernizao do sistema, segundo duas metodologias especficas:
Modernizao do tipo caixa branca

Modernizao do tipo caixa branca, a qual iniciada com um processo de
engenharia reversa, no qual componentes do sistema e seus relacionamentos
so identificados, gerando uma abstrao de alto nvel. Este tipo de
modernizao acaba levando necessidade de compreenso dos cdigos do
sistema e acaba incluindo alguma reestruturao do mesmo.
Modernizao do tipo caixa preta

Modernizao do tipo caixa preta, a qual envolve apenas a anlise de
entradas e sadas do sistema legado dentro de um contexto operacional, de
forma a identificar as interfaces desse sistema. Esse tipo de modernizao
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 comunicao com os atuais padres do
mercado.
Uso de SOA
O uso de SOA estimula a reutilizao dos aplicativos, os quais podero durar
dcadas. Ou seja, os sistemas implementados hoje podem ultrapassar seus
objetivos originais, sendo reutilizados na forma de componentes empresariais
virtualizados, gerenciados como caixas pretas acessadas atravs de interfaces
padronizadas.

Um exemplo de sistema crtico de difcil modificao so os que executam em
mainframes na rea bancria. Considerando o impacto monetrio de apenas
um dia parado, esses sistemas no permitem uma fcil substituio, e a criao
de uma camada de chamadas via servios, para acesso via novas tecnologias
acaba sendo uma soluo muito mais vivel e menos arriscada.
Com o uso de SOA possvel 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 tipos de componentes que podem

ser acessados em uma arquitetura orientada a servios, ao ilustrar algumas das
conexes disponibilizadas no Oracle SOA Suite.
O que garante essa grande conectividade em um ambiente SOA a presena

do ESB (Enterprise Service Bus), apoiado por diversos tipos de Middleware.

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 so aproveitados os diversos meios de interoperabilidade,

trabalhando de forma conjunta, o que viabiliza a integrao de aplicaes
distintas criadas em praticamente qualquer tecnologia recente ou legada.
Em alguns momentos, mais de uma tecnologia pode ser utilizada para acessar
determinada informao. Por exemplo, um mainframe poderia ser acessado via
JEE, e as informaes disponibilizadas dentro do SOA atravs de Web Services,
o que permitiria a outras plataformas, como dotNet, gerar clientes (consumers)
para os servios providos pelo servidor.
Em outras situaes podem ser utilizadas mensagerias para a comunicao com

outros sistemas, o que muito comum na rea financeira, o que permite

integrar o ambiente j existente de troca de mensagens com sistemas legados
de armazenagem desses dados, como mainframes via JEE, ou disponibilizar
para o pblico externo as informaes pertinentes sem a perda da segurana
no acesso aos dados tramitados no ambiente da mensageria.
Esse tipo de ambiente, com uso de mensagerias na rede privada, est presente
na comunicao entre instituies bancrias distintas, onde as solicitaes de
transferncia de valores so mensagens em formato XML criptografado com
chave 3DES, e assinado com chave privada RSA.
Outro elemento de grande utilizao dentro do ambiente SOA a conexo com

LDAP (Lightweight Directory Access Protocol), o que pode ser interessante para
a gesto de certificados digitais e da segurana em conjunto com o JAAS (Java
Authentication and Authorization Service).
Como um protocolo de aplicao aberto, voltados para a gesto de informaes

hierarquicamente organizadas, o LDAP um servio de diretrios utilizado
primordialmente para a gesto de informaes pessoais em ambiente
corporativo, sendo amplamente utilizado para a obteno de um logon nico
dentro de todo o ambiente.
Uso de Web Services

Embora a arquitetura orientada a servios seja um modelo conceitual, a
abordagem de Web Services a mais comum para sua implementao 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.
Atravs de Web Services possvel criar blocos funcionais de construo

acessveis atravs de protocolos de Internet padronizados de forma
independente de plataformas e linguagens de programao. Esses servios

podem representar tanto novas aplicaes quanto apenas invlucros em torno
dos sistemas legados existentes para disponibiliz-los no ambiente.
Neste tipo de abordagem, dois elementos principais devero ser considerados,

os quais so o Service Provider (provedor do servio) e o Consumer
(consumidor).
Service Provider - O provedor cria um Web Service e, eventualmente, publica

sua interface e acesso informao para o registro de servios. Cada
fornecedor deve decidir quais servios ir expor, como balancear entre aspectos
de segurana e facilidade de acesso. Tambm deve decidir em qual categoria
os servios devem ser listados em um dado Broker e que tipo de contrato ser
definido para a utilizao do servio. Ele registra os servios e as listas de todos
os perfis de acesso permitidos. Alguns Brokers so especializados em muitas
listas, enquanto outros oferecem altos nveis de confiana nos servios listados.
Alguns cobrem um amplo panorama de servios e outros tm foco dentro de
uma indstria especfica. O Universal Description Discovery and Integration
(UDDI) define uma maneira de publicar e descobrir informaes sobre os
servios da Web. Outros servios incluem (por exemplo) ebXML (Electronic
Business utilizando eXtensible Markup Language) e aqueles baseados na
ISO/IEC 11179 Metadata Registry (MDR) padro.
Consumer - O consumidor de servios, ou cliente do Web Service, localiza

entradas no registro do Broker para encontrar as operaes e, em seguida, liga-
se ao prestador do servio para invocar um de seus Web Services. Seja qual for
o servio que os consumers precisam, eles tm que solicit-lo ao Broker e, em
seguida, conectar com o respectivo servio e us-lo. Consumers podem acessar
vrios servios, se estiverem disponveis.
interessante observar que um provedor pode ser consumidor de outro

provedor, e que vrias operaes s podero ser efetuadas quando combinados
vrios servios atravs de orquestraes bem-definidas.

Quando esses agrupamentos ocorrem, para o usurio final fica disponvel
apenas o Web Service de solicitao primrio, ou seja, a interface de servios
para comunicao com o usurio atua como fachada para todos os demais
servios envolvidos.
Outra observao a de que, mesmo que um Web Service possa ser

disponibilizado diretamente, sem o uso do Broker, o ideal que o faa atravs
de outro Web Service disponibilizado pelo mesmo, de forma a no diminuir os
aspectos de segurana e governana da arquitetura orientada a servios.
Atividade proposta
Como atividade de fixao, instale o Oracle SOA Suite e faa uma anlise das
diversas opes de integrao oferecidas por esta plataforma SOA.
O download do produto est disponvel no seguinte endereo:
http://www.oracle.com/technetwork/middleware/soasuite/downloa
ds/index.html
Referncias
Saudate, A. SOA aplicado: Integrando com web services e alm. Editora Casa
do Cdigo, 2012.
Hirama, K. Fugita, H. Soa - Modelagem, Anlise e Design. Editora Campus,

2012.
Kaufman, M. Halper, F. Arquitetura Orientada a Servios SOA Para

Leigos. Editora Alta Books, 2009.

Exerccios de fixao
Questo 1
Considerando-se a abordagem de Web Services para uma Arquitetura
Orientada a Servios, o que so o OASIS ebXML e UDDI?
a) Protocolos de comunicao de Web Services.
b) Descritores de Servios.
c) Repositrios de informaes relacionados publicao de descoberta.
d) Gestores de segurana.
e) Ferramentas de autenticao e autorizao de usurios e componentes.
Questo 2
Em termos do SOA, analise as seguintes afirmativas:
I - Um servio definido como uma funo independente e sem estado
(stateless).
II Os servios devem se comunicar atravs de uma interface padronizada e
bem definida.
III - Um servio deve ser consumvel de forma prtica, com ferramentas para
descoberta e uso automatizado.
IV A nica desvantagem deste tipo de ambiente o grande aumento do
acoplamento.
Quantas afirmativas esto corretas?
a) Todas esto corretas.
b) Apenas uma est correta.
d) Apenas trs esto corretas.
e) Nenhuma est correta.
Questo 3
Um ambiente SOA deve ser independente de plataforma, conferindo a
caracterstica de:
a) baixo acoplamento
b) neutralidade

c) coeso
d) segurana
e) governana
Questo 4
Qual dos elementos abaixo NO est relacionado aos aspectos de segurana
em ambientes SOA?
a) Confidencialidade
b) Autenticao
c) Interoperabilidade
d) Autenticidade
e) Autorizao
Questo 5
Outra caracterstica desejvel em ambientes SOA a possibilidade de gesto de
polticas e processos necessrios boa utilizao da arquitetura, com a
definio de papis e determinao de objetivos claros. A descrio se refere a
qual caracterstica especfica?
a) baixo acoplamento
b) neutralidade
c) coeso
d) segurana
e) governana
Questo 6
O que viabiliza a grande conectividade do SOA a presena de um componente
principal denominado:
a) SOAP
b) XML
c) JDBC
d) RMI
e) ESB

Questo 7
Existem diversos tipos de conectores disponveis nas plataformas SOA. Entre as
opes seguintes, qual delas NO um conector que satisfaa filosofia de
utilizao do SOA?
a) SOAP
b) REST
c) CORBA
d) Mensagerias
e) JDBC
Questo 8
Existem vrias tcnicas que podem ser utilizadas para o reaproveitamento ou
adaptao de sistemas legados. No caso de ambientes SOA, a tcnica utilizada
seria:
a) Refatoramento
b) Modernizao do tipo "caixa preta"
c) Modernizao do tipo "caixa branca"
d) Herana
e) Substituio
Questo 9
Uma necessidade bastante comum em ambientes SOA a gesto de
segurana, e parte da soluo envolve a utilizao 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

Questo 10
Com relao abordagem de Web Services para ambientes SOA, considere as
seguintes afirmativas:
I Os dois principais papis utilizados so Service Provider e Consumer.
II Um provedor no pode ser consumidor de outro provedor.
III Podem ser combinados vrios servios atravs de processos de
orquestrao.
IV Sempre que possvel o Web Service deve ser acessado diretamente, sem a
real necessidade de uso do broker.
Quantas das afirmativas esto corretas?
a) Todas esto corretas.
b) Apenas uma est correta.
d) Apenas trs esto corretas.
e) Nenhuma est correta.

Aula 7
Exerccios de fixao
Questo 1 - C
Justificativa: Exemplos de repositrios so o OASIS ebXML e UDDI, tratando de
ferramentais onde podem ser armazenados e gerenciados artefatos como XML
Schemas e WSDL. Estes repositrios no tratam de aspectos relacionados
autenticao e demais elementos relacionados segurana da plataforma.
Quanto ao protocolo normalmente adotado, o SOAP, e o descritor de servios
mais comum o WSDL.
Questo 2 - D
Justificativa: Apenas a afirmativa IV est incorreta. Um termo muito utilizado
em termos de programao "acoplamento ", que trata do nvel de
interdependncia entre os mdulos de um sistema. Uma das caractersticas do
SOA justamente o baixo acoplamento, e o mdulo considerado coeso
quando possui uma atividade bem definida e um baixo acoplamento.
Questo 3 - B
Justificativa: Apesar de todas as caractersticas apresentadas serem desejveis
em um ambiente SOA, a independncia de plataforma denominada
neutralidade.
Questo 4 - C
Justificativa: A interoperabilidade uma premissa bsica para o SOA, porm
no faz parte dos aspectos de segurana desejados, como as demais opes,
inclusive aumentando a complexidade para que essas sejam implementadas
efetivamente.

Questo 5 - E
Justificativa: Apesar de todas as caractersticas apresentadas serem desejveis
em um ambiente SOA, esta gesto de papis e da boa utilizao do ambiente
denominada governana.
Questo 6 - E
Justificativa: O que garante a grande conectividade em um ambiente SOA,
viabilizando inclusive o reuso de sistemas legados, a presena do ESB
(Enterprise Service Bus), apoiado por diversos tipos de Middleware.
Questo 7 - E
Justificativa: Apenas o JDBC no poderia ser considerado um conector tpico
para SOA. Apesar de ser um middleware para acesso a bases de dados, o SOA
se preocupa com o acesso e orquestrao de servios, no 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.
Questo 8 - B
Justificativa: No caso do SOA utilizada a modernizao do tipo "caixa preta", a
qual envolve apenas a anlise de entradas e sadas do sistema legado dentro
de um contexto operacional, de forma a identificar as interfaces desse sistema,
ou seja, aproveitando os servios oferecidos pelo mesmo. No ocorre qualquer
tipo de refatoramento, o que alteraria o cdigo original, nem de extenses na
linguagem original, tipicamente por herana, como ocorre na modernizao
"caixa branca". Finalmente, o uso de SOA justificado em parte pela
impossibilidade de substituio do sistema legado.
Questo 9 - E
Justificativa: Incialmente, CORBA, RPC e RMI estariam relacionados conexo
com servios distribudos, alguns deles considerados legados, e as Mensagerias
esto relacionadas ao tratamento de solicitaes de forma assncrona.

Finalmente, um elemento de grande utilizao dentro do ambiente SOA a
conexo com LDAP (Lightweight Directory Access Protocol), o que pode ser
interessante para a gesto de certificados digitais e da segurana em conjunto
com tecnologias como o JAAS (Java Authentication and Authorization Service).
Questo 10 - C
Justificativa: As opes II e IV esto 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 faa atravs
de outro Web Service disponibilizado pelo mesmo, de forma a no diminuir os
aspectos de segurana e governana da arquitetura orientada a servios.

Introduo
As arquiteturas orientadas a servios apresentam componentes comuns, cujas
funcionalidades devem ser compreendidas corretamente, no intuito de melhor
aproveitar as caractersticas desse tipo de ambiente.
Termos como ESB, BPMN e BPEL so comuns no que se refere ao controle,

composio e exposio de servios, sendo necessrio compreender a
modelagem de processos e o uso de linguagens e notaes especficas para a
orquestrao dos diversos servios e recursos.
Ferramentas como Oracle SOA Suite, IBM SOA Foundation e JBoss Enterprise
SOA Platform encontram nesses termos um vocabulrio e funcionalidades
comuns.
Objetivo:
1. Compreender a importncia de elementos como ESB e Middleware;
2. Apresentar o conceito de Orquestrao de Servios e uso do BPMN e do
BPEL.
Contedo
ESB e middleware
Quando falamos de middleware, ou software intermedirio, estamos nos
referindo a tecnologias que permitem a criao de uma camada intermediria
para a comunicao de dois ou mais componentes de software.

O middleware normalmente utilizado para isolar o nvel de Back-End do Front-
End, garantindo a independncia com relao ao fornecedor do Back-End,
como no caso do banco de dados, onde as opes as mais diversas, incluindo
Oracle, MySQL, DB2, Informixso , Jasmine, Postgre SQL, SQL Server, entre
outros.
Com a utilizao de um middleware possvel generalizar as solues de

software, aumentando a reutilizao de um dado componente em ambientes
diversos.
A figura seguinte demonstra o uso de algumas famlias de middlewares de

acesso a banco de dados por diferentes ferramentas.
De um ponto de vista mais amplo, vrios elementos podem ser considerados

middleware, como por exemplo:
Remote Procedure Call (RPC) Requisita a execuo de

procedimentos remotos.

Message Oriented Middleware (MOM) Fornece acesso a um
servio de mensagens.
Object Request Broker (ORB) Possibilita a comunicao com envio

de objetos e solicitaes.
SQL-oriented Data Access Deixa transparente o acesso a bancos

de dados.
Metodologia de comunicao
Nas arquiteturas orientada a servios, onde sistemas heterogneos
disponibilizam componentes com protocolos de comunicao distintos, existe
uma grande dependncia da utilizao de middleware com as mais diversas
finalidades.
Em arquiteturas tradicionais do tipo ponto a ponto, a comunicao direta entre

aplicaes poder levar o sistema como um todo ao colapso, j que a
complexidade da integrao cresce de forma exponencial. Com quatro
servidores se comunicando dessa forma ocorrero seis possibilidades de
conexo, enquanto com seis servidores o nmero sobe para quinze conexes, e
dentro de um ambiente corporativo, como dezenas e at centenas de
servidores cooperando, essa arquitetura acaba sendo invivel.
Baseando-se nas informaes anteriores, foi concebida uma nova metodologia

de comunicao entre sistemas por meio de um canal centralizador, algo
prximo do que ocorre no uso de mensagerias, porm aqui sendo tratados
servios e componentes heterogneos.
Com isso, surge o termo ESB (Enterprise Service Bus), referente camada de
middleware de negcios de uma arquitetura orientada a servios. Basicamente
trata do ncleo da arquitetura, agrupando todas as tecnologias de comunicao

com os diversos tipos de componentes suportados pelo software gestor dessa
arquitetura.
Ateno
A palavra "bus" (barramento) uma referncia ao meio fsico

que carrega bits entre dispositivos em um computador. O ESB
prov uma funo anloga em alto nvel de abstrao.
Considerando uma arquitetura empresarial que faa uso de um ESB, uma

aplicao ir se comunicar via barramento, que atua como um message broker
entre aplicaes. A principal vantagem dessa abordagem a reduo de
conexes ponto a ponto necessrias para permitir a comunicao entre
aplicaes. Isso, por sua vez, afeta diretamente a simplificao da manuteno
do sistema, pois ao reduzir o nmero de conexes ponto a ponto para uma
aplicao especfica, o processo de adapatao desse sistema s mudanas em
um de seus componentes torna-se mais fcil.
Adoo de um ESB

A adoo de um ESB promove grande atomicidade para os servios, e com isso,
se um sistema tiver de ser reescrito, particionado ou qualquer outro tipo de
mudana, atravs do barramento que ser resolvida a comunicao,
mantendo-se intactas as interfaces dos demais sistemas envolvidos.
Ateno
Normalmente um ESB apresenta grande complexidade,

envolvendo todo o ferramental necessrio para o acesso a
ambientes heterogneos, onde podem estar presentes
mainframes, bancos de dados, servios SOAP e REST, sockets,
mensagerias, entre muitos outros elementos.
Aplicao do ESB
Com o uso do ESB possvel integrar em um mesmo ambiente, mantendo a
independncia de cada componente, dados, fluxos de execuo, servios de
forma geral, B2B, ferramentas de publicao para portais, aplicaes legadas e
novos elementos de software, como pode ser visto na figura seguinte:

Como exemplo de arquitetura comercial de um ESB, a figura apresentada
representa a composio do JBoss ESB.
As funes principais de um ESB so:

Monitorar e controlar o roteamento das mensagens trocadas entre
servios.
Resolver disputa na comunicao entre componentes de servio.
Controlar a implantao e o versionamento de servios.
Conduzir o uso de servios redundantes.
Atender a servios corporativos compartilhados, como a manipulao de

eventos, transformao de dados e mapeamento, mensagem e evento filas e
sequenciamento, manipulao de segurana ou exceo, converso de
protocolo e gerenciamento adequados da qualidade de servio de comunicao.
Alm da grande diversidade de middleware presente no ESB, a gerncia do

fluxo de chamadas e respostas deve ser feita segundo um processo de
composio e orquestrao de servios.
Muitas vezes, ocorre uma grande confuso entre orquestrao e coreografia de

servios. Em termos de orquestrao existe um ambiente mediador, sendo a
ativao e coordenao das diversas chamadas e respostas sempre efetuadas
atravs dele, enquanto que para a coreografia no existe esse coordenador
central, e por consequncia todos os participantes se conhecem e atuam de
forma colaborativa.
Ateno
Para efetuar a coreografia de servios podem ser utilizados

elementos como o WS-CI (Web Service Choreography Interface)
e o WS-CDL (Web Service Choreography Description Language),
mas em termos de arquiteturas orientadas a servio, a
orquestrao com uso de BPEL (Business Process Execution
Language) torna-se mais efetiva.

Orquestrao de servios
A orquestrao de servios definida como o processo de sequenciar servios e
prover uma lgica adicional para processar dados, no incluindo uma
representao desses dados. Essa orquestrao facilitada com o uso de
notaes grficas e linguagens especficas.
No mercado dos BPMS (Business Process Management Systems, ou Sistemas de

Gerenciamento de Processos de Negcios), verificase a existncia de duas
tendncias ligadas a dois dos standards: BPEL (Business Process Execution
Language ) e BPMN (Business Process Modelling Notation).
O uso de BPEL refere-se aos aspectos de execuo, ficando assim mais prximo
da implementao. Com relao ao BPMN, ele traz uma grande aceitao por
tratar de uma notao grfica para a representao de processos de negcio.
A adoo desses dois ferramentais comum no SOA, e enquanto essas

ferramentas possibilitam atingir a excelncia nos processos, padronizao e
automao, a arquitetura de execuo do SOA viabiliza grande reutilizao,
governana e segurana.

Um exemplo de uso pode ser observado ao lado, com a definio de um
processo que envolve a chamada a um Web Service externo em BPEL 2.0,
dentro do ambiente grfico do Oracle SOA Suite.
BPMN
Quando falamos de BPMN nos referimos a uma notao grfica utilizada para
representar processos de negcio, sendo a mesma composta por um conjunto
de smbolos padronizados, os quais so organizados em um diagrama de
processos de negcio.
O objetivo do BPMN comunicar informaes diversas com diferentes pblicos

de forma organizada. Entre os envolvidos podem ser encontrados: analistas de
negcio, desenvolvedores e interessados nos processos de forma geral
(gerentes, coordenadores etc.).
Elementos bsicos do BPMN:
Eventos, tratando de elementos que afetam o fluxo do processo de

negcio.
Atividades, referindo-se a comandos executados durante o processo,
podendo ser atmicas ou compostas.
Gateway, o qual controla a convergncia ou divergncia do fluxo.
Evento
Ocorrncia que dispara uma atividade e so categorizadas pelo tipo (incio,
intermedirio e fim) e pelo gatilho (nenhum, mensagem, temporizador,
condicional, sinal, exceo, cancelamento, compensao, ligao, mltiplo ou
terminao). O smbolo bsico de um evento um pequeno crculo que pode
ser complementado pelo seu tipo e seu gatilho; o incio representado por uma
borda fina; o evento intermedirio representado por uma borda dupla; e o
evento de fim representado por uma borda espessa.

Atividade
Trabalho executado dentro de um processo de negcio podendo ser atmico ou
no atmico (composto). Atividades que fazem parte de um diagrama de
processos de negcio so classificadas como: processos, subprocessos ou
tarefas. O processo em si no um objeto grfico especfico, mas um conjunto
de objetos grficos.
Tarefa (Task) - Atividade atmica que includa dentro de um processo.

usada quando o trabalho em um processo no quebrado em um nvel menor
de detalhe do modelo de processo.
Subprocesso (Sub-Process) - Atividade composta que possui detalhes

definidos por uma sequncia de outras atividades. Pode ser observado como
um objeto grfico dentro de um fluxo de processo, mas possibilita a expanso
para exibir outro processo embutido ou reutilizvel.
Para determinar o fluxo do processo, as atividades e os eventos so

relacionados atravs de objetos de conexo especficos.

Gateway
Gateways so elementos utilizados para controlar a convergncia ou

divergncia do fluxo ao longo de sua execuo. Se o fluxo no precisa ser
controlado, no precisamos utilizar Gateways, pois os mesmos so opcionais.
Toda a simbologia aqui utilizada foi definida nas normatizaes de 2005 da

OMG (Object Management Group).
Pool e Lane
Um pool utilizado para representar um participante do processo, como a
empresa ou algum elemento externo, como cliente ou fornecedor.
Em um modelo B2B os pools permitem representar diferentes empresas se
comunicando em seus processos de negcio.
Cada Pool poder envolver vrios processos, porm pode ser necessrio
trabalhar com uma diviso maior, ao nvel da estrutura interna da empresa,
sendo utilizadas divises denominadas Lanes.

Pool utilizado para separar dois participantes de um processo de negcios
fisicamente separados, sendo a comunicao entre os mesmos atravs de
mensagens.
Lane uma diviso dentro de um pool, identificando

participantes dentro de uma mesma organizao.
Em termos de governana, o uso de BPMN permite um olhar muito organizado

sobre os processos de negcio da empresa, trazendo os requisitos necessrios
para a definio dos diversos modelos dos processos de negcios, e
viabilizando o mapeamento para a implementao BPEL adequada, como
prope a figura seguinte.

BPEL
A linguagem BPEL tem como objetivo efetuar a orquestrao da chamada de
servios, segundo uma sintaxe baseada em XML, sendo voltada para Web
Services, isto devido s atuais caractersticas dos diversos provedores para
SOA.
Historicamente, IBM e Microsoft definiram, respectivamente, as linguagens de

orquestrao de servios: WSFL (Web Service Flow Language) e XLANG (XML
LANGuage). Com o advento e a popularidade do BPML, e o sucesso crescente
de BPMI.org, IBM e Microsoft decidiram combinar essas linguagens em um
novo idioma, BPEL4WS. Em abril de 2003, o consrcio formado por BEA
Systems, IBM, Microsoft, SAP e Siebel Systems apresentou o BPEL4WS 1.1
OASIS para a normalizao. Em 14 de setembro de 2004 ocorre a alterao do
nome para "WS-BPEL 2.0", incluindo diversas melhorias, sendo hoje
comumente denominado BPEL 2.0
Apesar de alinhada com uma interpretao grfica bastante prxima do BPMN,

a sintaxe BPEL no precisa de diagramas, mas simplesmente do uso de XML.

Alguns dos elementos que podem ser encontrados em um arquivo BPEL podem
ser visualizados na tabela seguinte.
Estes so apenas alguns dos elementos presentes na sintaxe. Em verdade BPEL

uma linguagem muito rica, com vrios recursos voltados para o controle,
sequenciamento e comunicao de servios.
O cdigo-fonte BPEL para a notao grfica
<?xml version = "1.0" encoding = "UTF-8" ?>


<process name="BPELTeste001"
targetNamespace="http://xmlns.oracle.com/TesteSOA001/ProjSOA001/BPELTe
ste001"
xmlns="http://docs.oasis-open.org/wsbpel/2.0/process/executable"
xmlns:client="http://xmlns.oracle.com/TesteSOA001/ProjSOA001/BPELTeste00
1"
xmlns:ora="http://schemas.oracle.com/xpath/extension"
xmlns:ui="http://xmlns.oracle.com/soa/designer"
xmlns:bpelx="http://schemas.oracle.com/bpel/extension"
xmlns:bpel="http://docs.oasis-
open.org/wsbpel/2.0/process/executable" xmlns:ns1="http://webscalc/">
<import ui:processWSDL="true"
namespace="http://xmlns.oracle.com/TesteSOA001/ProjSOA001/BPELTeste001
" location="../WSDLs/BPELTeste001.wsdl"
importType="http://schemas.xmlsoap.org/wsdl/"/>

<partnerLinks>
<partnerLink name="bpelteste001_client"
partnerLinkType="client:BPELTeste001"

myRole="BPELTeste001Provider"
partnerRole="BPELTeste001Requester"/>
<partnerLink name="SOAPReference1"
partnerLinkType="ns1:SOAPReference1" partnerRole="WebSCalc"/>
</partnerLinks>

<variables>
<variable name="inputVariable"
messageType="client:BPELTeste001RequestMessage"/>
<variable name="outputVariable"
messageType="client:BPELTeste001ResponseMessage"/>
<variable name="Invoke1_add_InputVariable"
messageType="ns1:add"/>
<variable name="Invoke1_add_OutputVariable"
messageType="ns1:addResponse"/>
</variables>

<sequence name="main">
<receive name="receiveInput" partnerLink="bpelteste001_client"
portType="client:BPELTeste001" operation="process"
variable="inputVariable" createInstance="yes"/>
<invoke name="Invoke1" partnerLink="SOAPReference1"
portType="ns1:WebSCalc" operation="add"
inputVariable="Invoke1_add_InputVariable"
outputVariable="Invoke1_add_OutputVariable"
bpelx:invokeAsDetail="no"/>
<invoke name="callbackClient" partnerLink="bpelteste001_client"
portType="client:BPELTeste001Callback" operation="processResponse"
inputVariable="outputVariable"/>
</sequence>
</process>

Atividade proposta
Baseado no exerccio anterior, acerca de Web Services, ser criado um
processo BPEL no Oracle SOA Suite. Caso no tenha efetuado o exerccio, crie
agora um Web Service de calculadora com as quatro operaes bsicas atravs
do NetBeans.
Com a WSDL fornecida pelo Web Service criado, acesse o mesmo a partir do
Oracle SOA Suite e defina um processo BPEL para prover um novo servio que
efetuar o clculo de saldo baseado em juros simples ou compostos, o que
deve ocorrer atravs de um processo de orquestrao de chamadas ao Web
Service de calculadora.
Observao:
Onde C = Capital Inicial, t = Taxa de Juros, n = Perodo.

Referncias
Saudate, A. SOA aplicado: Integrando com web services e alm, Editora Casa
do Cdigo, 2012.
Hirama, K. Fugita, H. Soa - Modelagem, Anlise e Design. Editora Campus,

2012.
Kaufman, M. Halper, F. Arquitetura Orientada a Servios SOA Para

Leigos. Editora Alta Books, 2009.
Business Process Model and Notation (BPMN). OMG, 2011.

http://www.omg.org/spec/BPMN/2.0/PDF/
Web Services Business Process Execution Language Version 2.0.

OASIS,2007. http://docs.oasis-open.org/wsbpel/2.0/wsbpel-v2.0.pdf

Exerccios de fixao
Questo 1
Na arquitetura SOA, o acesso aos diversos tipos de tecnologias englobados
feito por intermdio da estrutura denominada:
a) RPC
b) ESB
c) CORBA
d) RMI
e) JEE
Questo 2
"Quando trabalhamos com servios de forma colaborativa existem duas formas
de organiz-los e sequenci-los. Na prtica denominada ___________ existe
um ambiente mediador, sendo a ativao e coordenao das diversas
chamadas e respostas sempre efetuadas atravs deste, enquanto que no
modelo denominado ______________ no existe este coordenador central, e
por consequncia todos os participantes se conhecem e atuam de forma
colaborativa."
Qual opo completa corretamente as lacunas?
a) Coreografia e broadcast.
b) Coreografia e orquestrao.
c) Coreografia e ESB.
d) Orquestrao e ESB.
e) Orquestrao e coreografia.
Questo 3
Qual o nome adotado para a camada intermediria entre dois ou mais
componentes de software?
a) Front-end
b) ESB
c) Middleware
d) Back-end

e) MOM
Questo 4
Como ncleo da Arquitetura Orientada a Servios, o ESB cumpre com vrias
tarefas referentes aos servios. Qual das opes abaixo NO uma destas
tarefas?
a) Transformao
b) Roteamento
c) Gerncia
d) Segurana
e) Implementao
Questo 5
Considere as seguintes afirmativas:
I A linguagem BPEL amplamente utilizada na orquestrao de servios.
II Outra opo de linguagem para efetuar a orquestrao a WS-CDL.
III Toda a comunicao do ESB com outras tecnologias deve utilizar Web
Services.
Qual das opes est correta?
a) Apenas a afirmativa I verdadeira.
b) So verdadeiras as afirmativas II e III.
c) Apenas a afirmativa II falsa.
d) Todas as afirmativas so verdadeiras.
e) Todas as afirmativas so falsas.
Questo 6
Os elementos bsicos fornecidos pelo BPMN para a modelagem de processos
so:
a) Eventos, Atividades e Tarefas.
b) Eventos, Tarefas e Gateways.
c) Eventos, Tarefas e Subprocessos.
d) Atividades, Tarefas e Subprocessos.

e) Eventos, Atividades e Gateways.
Questo 7
Considere as afirmativas acerca do seguinte fluxo de processo:
I "Lottery Retailer " e "Customer " so pools, definindo duas instituies

diferentes.
II "Wait for result" um evento simples.
III O processo todo iniciado por "Order received".
Qual das opes verdadeira?
a) Todas as afirmativas esto corretas.
b) As afirmativas II e III esto corretas.
c) Apenas a afirmativa I est correta.
d) As afirmativas I e II esto corretas.
e) Nenhuma afirmativa est correta.
Questo 8
Segundo a BPMN, o que significa o smbolo abaixo?

a) Atividade Ad-hoc.
b) Subprocesso que repete a si prprio (loop).
c) Tarefa que repete a si prpria (loop).
d) Tarefa de compensao.
e) Subprocesso de mltiplas instncias.
Questo 9
Em termos de BPEL, quais comandos fazem, respectivamente, a chamada a um
servio e a recepo da resposta de uma fonte externa?
a) Os comandos invoque e receive.
b) Os comandos invoque e partnerLink.
c) Os comandos invoque e assign.
d) Os comandos assign e partnerLink.
e) Os comandos partnerLink e assign.
Questo 10
Qual comando BPEL deve ser utilizado quando precisamos escolher uma entre
vrias atividades?
a) process
b) throw
c) terminate
d) switch
e) while

Aula 8
Exerccios de fixao
Questo 1 - B
Justificativa: O termo ESB (Enterprise Service Bus), refere-se camada de
middleware de negcios de uma arquitetura orientada a servios. Basicamente
trata do ncleo da arquitetura, agrupando todas as tecnologias de comunicao
com os diversos tipos de componentes suportados pelo software gestor desta
arquitetura. As demais opes apresentadas tratam justamente de tecnologias
que costumam ser acessadas por intermdio do ESB nesta arquitetura.
Questo 2 - E
Justificativa: A orquestrao de servios exige um mediador central, o qual
normalmente constitudo do ESB e ferramentas de apoio no SOA, enquanto a
coreografia no trabalha com este mediador, trazendo um ambiente em que os
servios colaboram diretamente uns com os outros.
Questo 3 - C
Justificativa: Quando falamos de middleware estamos nos referindo a
tecnologias que permitem a criao de uma camada intermediria para a
comunicao de dois ou mais componentes de software.
O middleware normalmente utilizado para isolar o nvel de Back-End do Front-
End, sendo o MOM um exemplo de tipo de middleware especfico para
mensagerias.
Quanto ao ESB, ele precisa de grande diversidade de middlewares para garantir
toda a interoperabilidade desejada.
Questo 4 - E
Justificativa: O ambiente SOA se preocupa com a gerncia, segurana e
orquestrao de servios, mas no com a implementao dos mesmos, fato
este que garante a grande neutralidade deste ambiente.

Questo 5 - A
Justificativa: A afirmativa II falsa, pois WS-CDL uma linguagem para
coreografia de servios, e no orquestrao. Quanto afirmativa III, o ESB
concentra uma grande gama de middleware para acesso a diferentes tipos de
tecnologias, logo no ficando restrito aos Web Services.
Questo 6 - E
Justificativa: Elementos bsicos do BPMN:
- Eventos, tratando de elementos que afetam o fluxo do processo de negcio.
- Atividades, referindo-se a comandos executados durante o processo, podendo
ser atmicas ou compostas.
- Gateway, o qual controla a convergncia ou divergncia do fluxo.
Questo 7 - C
Justificativa: A afirmativa I est correta, e certamente muitas pessoas
confundiriam estes pools com lanes. Quanto afirmativa II, est incorreta pois
o elemento trata de um Gateway. Por fim, todo o processo iniciado por "Start
Event", o que invalida a afirmativa III, at mesmo porque o elemento
considerado possui dependncia de "Buy a ticket".
Questo 8 - B
Justificativa: A simbologia das atividades pode ser observada a seguir. O
smbolo de "+" indica um subprocesso fechado (fora da forma expandida), e a
simbologia utilizada a de loop.

Questo 9 - A
Justificativa: Os comandos so invoque e receive, como pode ser observado
nos descritivos abaixo.
Questo 10 - D
Justificativa: O comando switch, como pode ser observado nos descritivos
abaixo.

Rogrio Leito Nogueira Mestre em Educao Tecnolgica, Ps graduado
em Docncia Superior, Graduado em Processamento de Dados, Professor da
rea de TI na UNESA h 15 anos e Professor e coordenador do curso de
Sistemas de Informao da FAETERJ Paracambi - FAETEC.

14785589987745587

Загружено:

Сведения о документе

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

14785589987745587

Загружено:

Авторское право:

Доступные форматы

Apresentao ............................................................................................................................

ARQUITETURA ORIENTADA A SERVIOS - SOA E WEBSERVICES 1

ARQUITETURA ORIENTADA A SERVIOS - SOA E WEBSERVICES 2

ARQUITETURA ORIENTADA A SERVIOS - SOA E WEBSERVICES 3

ARQUITETURA ORIENTADA A SERVIOS - SOA E WEBSERVICES 4

Sendo assim, essa disciplina tem como objetivos:

ARQUITETURA ORIENTADA A SERVIOS - SOA E WEBSERVICES 5

Esta aula visa demonstrar os elementos histricos que trouxeram essa

ARQUITETURA ORIENTADA A SERVIOS - SOA E WEBSERVICES 6

Histrico da integrao de sistemas

Muitos projetos apresentavam caractersticas semelhantes, mas, como no

Em meados da dcada de 90, com a expanso dos sistemas, comearam a ser

Essa no uma preocupao nova. Na rea de engenharia, sempre ocorreram

Para baratear e agilizar a produo de um novo sistema de engenharia so

ARQUITETURA ORIENTADA A SERVIOS - SOA E WEBSERVICES 7

Esses componentes, ao apresentarem interfaces padronizadas, podem ser

Na rea da informtica, as atuais arquiteturas de software divididas em

Fatores considerados na escolha de COTS

Quanto longevidade do componente, existem preocupaes acerca da

Alm desses, outros fatores considerados na escolha de COTS, tanto software

ARQUITETURA ORIENTADA A SERVIOS - SOA E WEBSERVICES 8

Ainda nesta disciplina, observaremos as diversas formas de interoperabilidade

Integrao via banco de dados

As ferramentas de programao antigas tinham bibliotecas de acesso para

Essa dependncia da ferramenta em relao ao banco em termos de

Na abordagem atual, de um lado, temos o back-end, representado pelos

ARQUITETURA ORIENTADA A SERVIOS - SOA E WEBSERVICES 9

Com essa modificao na concepo dos sistemas, hoje possvel programar

Vantagens que essa abordagem inclui:

Infelizmente, nem tudo positivo, e alguns pontos negativos devem ser

O uso de SQL proprietrio, como PL-SQL, pode diminuir a portabilidade do

ARQUITETURA ORIENTADA A SERVIOS - SOA E WEBSERVICES 10

Apesar dos problemas apresentados, o uso de middleware

O termo middleware no se restringe ao uso de banco de dados,

Integrao via protocolo

Em termos gerais, o protocolo a formalizao da comunicao e transferncia

ARQUITETURA ORIENTADA A SERVIOS - SOA E WEBSERVICES 11

Um protocolo pode ser definido em diversas camadas de rede, segundo o

(Figura representativa das camadas de rede)

Outro exemplo so os diversos programas clientes de Telnet, criados nas mais

Como o foco maior do mercado so as redes TCP-IP, o uso de Sockets, onde

ARQUITETURA ORIENTADA A SERVIOS - SOA E WEBSERVICES 12

Com protocolos de comunicao bem definidos, duas

Um sistema interopervel deve permitir acesso a suas funcionalidades segundo

Embora seja antigo o interesse da engenharia de sistemas pelo tema,

O interesse de empresas e rgos governamentais pelo tema pode ser

ARQUITETURA ORIENTADA A SERVIOS - SOA E WEBSERVICES 13

Com a disponibilizao deste tipo de funcionalidade, tornou-se muito comum

Mas a interoperabilidade vai muito alm disso, e o elemento principal para

Quando uma metodologia ou ferramental tecnolgico promete

As plataformas que viabilizavam a criao desses tipos de componentes

ARQUITETURA ORIENTADA A SERVIOS - SOA E WEBSERVICES 14

Com o uso dessa interface-padro de programao e ativao de objetos

Em termos de redes, inicialmente as interfaces eram baseadas na simples

Paralelamente, surgiram sistemas de mensageria que permitiam trabalhar de

Os ambientes de objetos distribudos comearam a ser utilizados, com a

ARQUITETURA ORIENTADA A SERVIOS - SOA E WEBSERVICES 15

Tomando como exemplo a questo do servio de localizao e registro de

Alm dos exemplos comercialmente conhecidos e que apresentam reas fins

Hoje em dia, muito mais fcil obter um meio de armazenamento compatvel

ARQUITETURA ORIENTADA A SERVIOS - SOA E WEBSERVICES 16

Tambm na rea de software essa independncia de fornecedores foi bastante

A definio de arquiteturas e metodologias independentes de plataforma ou

Um exemplo utilizado para promover essa independncia, j citado