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