14785589987745587

Apresentação ............................................................................................................................ 5 Aula 1: Interoperabilidade - Necessidades e Conceitos ................................................ 6 Introdução ............................................................................................................................. 6 Conteúdo................................................................................................................................ 7 Histórico da integração de sistemas .............................................................................. 7 Fatores considerados na escolha de COTS .................................................................. 8 Integração via banco de dados ....................................................................................... 9 Integração via protocolo ................................................................................................ 11 Interoperabilidade ........................................................................................................... 13 Padronização de interfaces ........................................................................................... 14 Independência de fornecedores ................................................................................... 16 Atividade proposta .......................................................................................................... 18 Referências........................................................................................................................... 18 Exercícios de fixação ......................................................................................................... 19 Chaves de resposta ..................................................................................................................... 23 Aula 2: Arquitetura Voltadas para Interoperabilidade ................................................ 25 Introdução ........................................................................................................................... 25 Conteúdo.............................................................................................................................. 26

High level architecture .................................................................................................... 26 HLA e RTI........................................................................................................................... 27 Mensagerias ...................................................................................................................... 32 Fila....................................................................................................................................... 33 Tópicos .............................................................................................................................. 34 Utilização de mensagerias ............................................................................................. 35

Message driven bean ....................................................................................................... 36 Atividade proposta .......................................................................................................... 38 Referências........................................................................................................................... 38 Exercícios de fixação ......................................................................................................... 39 Chaves de resposta ..................................................................................................................... 43 Aula 3: Processamento Distribuído com RPC e RMI ..................................................... 45 Introdução ........................................................................................................................... 45 Conteúdo.............................................................................................................................. 46 Processamento paralelo ................................................................................................. 46

ARQUITETURA ORIENTADA A SERVIÇOS - SOA E WEBSERVICES

1

Processamento distribuído ............................................................................................ 48 RPC (Remote Procedure Call)......................................................................................... 50 RM(Remote Method Invocation).................................................................................... 54

Marshalling e Unmarshalling .......................................................................................... 57 Serviços de nomes e diretórios ..................................................................................... 58 Atividade proposta .......................................................................................................... 59 Referências........................................................................................................................... 59 Exercícios de fixação ......................................................................................................... 60 Chaves de resposta ..................................................................................................................... 64 Aula 4: Objetos Distribuído com CORBA e JEE .............................................................. 66 Introdução ........................................................................................................................... 66 Conteúdo.............................................................................................................................. 67 Objetos distribuídos ........................................................................................................ 67 CORBA ............................................................................................................................... 69 RMI-IIOP ............................................................................................................................ 71

Java Enterprise Edition .................................................................................................... 74 Chamada de JEE por ferramentas CORBA ................................................................. 78 Atividade proposta .......................................................................................................... 83 Referências........................................................................................................................... 83 Exercícios de fixação ......................................................................................................... 84 Chaves de resposta ..................................................................................................................... 88 Aula 5: Tecnologias Voltadas para XML .......................................................................... 91 Introdução ........................................................................................................................... 91 Conteúdo.............................................................................................................................. 92 Sintaxe XML ....................................................................................................................... 92 Documento XML .............................................................................................................. 94 Entidades ........................................................................................................................... 96 Exemplo da W3C .............................................................................................................. 97 Formas gramaticais em XML ......................................................................................... 99 Linguagens de transformação .................................................................................... 100 XSLT .................................................................................................................................. 101 XSL-FO ............................................................................................................................. 103 Outras tecnologias XML................................................................................................ 106 Atividade proposta ........................................................................................................ 106 Referências......................................................................................................................... 107 Exercícios de fixação ....................................................................................................... 108

ARQUITETURA ORIENTADA A SERVIÇOS - SOA E WEBSERVICES

2

Chaves de resposta ................................................................................................................... 111 Aula 6: Interoperabilidade com XML - RPC e Web Services ..................................... 114 Introdução ......................................................................................................................... 114 Conteúdo............................................................................................................................ 115 XML-RPC .......................................................................................................................... 115 Implementação em Java.............................................................................................. 118 SOAP................................................................................................................................. 119 Web Services................................................................................................................... 122

SOAP Web Services ........................................................................................................ 122 UDDI ................................................................................................................................. 124 Criação de SOAP Web Services em Java .................................................................. 125 Criação de Cliente dotNet ........................................................................................... 126 Sistemas B2B e B2C ....................................................................................................... 127 Atividade proposta ........................................................................................................ 128 Referências......................................................................................................................... 129 Exercícios de fixação ....................................................................................................... 130 Chaves de resposta ................................................................................................................... 134 Aula 7: Arq. Orientadas a Serviços - Conceitos e Definições ................................... 137 Introdução ......................................................................................................................... 137 Conteúdo............................................................................................................................ 138 Princípios do SOA .......................................................................................................... 138 Conceitos de arquitetura orientada a serviço .......................................................... 140 Governança e Segurança ............................................................................................. 141 Telas sobre governança ............................................................................................... 142 Aspectos de segurança ................................................................................................. 143 Integração e uso de tecnologias legadas.................................................................. 145 Uso de SOA ..................................................................................................................... 146 Uso de Web Services...................................................................................................... 149 Atividade proposta ........................................................................................................ 151 Referências......................................................................................................................... 151 Exercícios de fixação ....................................................................................................... 152 Chaves de resposta ................................................................................................................... 156 Aula 8: Arq. Orientadas a Serviços - ESB, BPMN e BPEL ............................................ 159 Introdução ......................................................................................................................... 159 Conteúdo............................................................................................................................ 159 ESB e middleware ........................................................................................................... 159

ARQUITETURA ORIENTADA A SERVIÇOS - SOA E WEBSERVICES

3

Metodologia de comunicação .................................................................................... 161 Adoção de um ESB ........................................................................................................ 162 Aplicação do ESB ........................................................................................................... 163 Orquestração de serviços............................................................................................. 166 BPMN................................................................................................................................ 167 Evento .............................................................................................................................. 167 Atividade .......................................................................................................................... 168

Gateway ........................................................................................................................... 169 Pool e Lane ...................................................................................................................... 169 BPEL .................................................................................................................................. 171 Atividade proposta ........................................................................................................ 176 Referências......................................................................................................................... 177 Exercícios de fixação ....................................................................................................... 178 Chaves de resposta ................................................................................................................... 182 Conteudista ........................................................................................................................... 185

ARQUITETURA ORIENTADA A SERVIÇOS - SOA E WEBSERVICES

4

Conceito de arquitetura da informação. Metodologia de arquitetura da informação para websites. Organização do conteúdo, Sistema de navegação, Sistema de rotulagem e busca. Estudo de usuários e do ambiente. Testes de usabilidade. Modelagem. Conceituação e visão macroscópica de sites. Representação: sitegrama, wireframes, etc. Implentação de sites. Sendo assim, essa disciplina tem como objetivos: 1. Compreender a importância e organização do fluxo de informação visando torná-la útil através de planejamento e mapeamento visual e contextual, assegurando a facilidade de utilização em um sistema de aplicação local ou web. 2. Conhecer um pouco da história da informação na vida das pessoas e das organizações. 3. Compreender as semelhanças e diferenças entre a arquitetura convencional e na construção de sistemas computacionais. 4. Conhecer conceito e atributos de usabilidade. 5. Compreender a importância da arquitetura da informação, o conhecimento de seus componentes e o esquema de organização na criação de websites. . 6. Conhecer a importância de design estrutural de ambientes de informação compartilhados.

ARQUITETURA ORIENTADA A SERVIÇOS - SOA E WEBSERVICES

5

Introdução A necessidade de integração entre plataformas heterogêneas sempre foi uma necessidade nas áreas tecnológicas; e, no decorrer de várias décadas, métodos cada vez mais especializados em termos de hardware e software foram evoluindo para que tal necessidade fosse suprida, permitindo o aumento do reuso, diminuição de custos e melhoria das possibilidades de manutenção devido à obsolescência. Esta aula visa demonstrar os elementos históricos que trouxeram essa necessidade à tona e quais metodologias básicas foram implementadas para esse tipo de integração, culminando com o atual conceito de interoperabilidade.

Objetivo: 1. Entender as metodologias primárias de integração e problemas relacionados a elas; 2. Compreender o conceito de interoperabilidade e técnicas atuais para a sua obtenção.

ARQUITETURA ORIENTADA A SERVIÇOS - SOA E WEBSERVICES

6

Conteúdo Histórico da integração de sistemas Com a expansão dos elementos tecnológicos no decorrer da história, começaram a aparecer grandes conjuntos de dados independentes, os quais não se comunicavam, gerando uma grande redundância de informações e desperdício de poder de processamento. Muitos projetos apresentavam características semelhantes, mas, como não existiam interfaces comuns, ocorria um grande retrabalho na construção de novos produtos e bases de dados. Em meados da década de 90, com a expansão dos sistemas, começaram a ser oferecidas diferentes formas padronizadas de armazenar, recuperar e processar dados de origem externa aos aplicativos. Através de conversores de dados, os arquivos de um determinado fabricante eram convertidos para um determinado formato, de forma que outro fabricante pudesse ler. Esse processo surgiu da necessidade de compartilhamento de dados entre aplicativos distintos. Essa não é uma preocupação nova. Na área de engenharia, sempre ocorreram problemas quanto à obsolescência e preocupações com manutenções. Não é raro o fato de um fornecedor falir ou um componente sair de linha, encarecendo

demasiadamente

a

continuidade

do

funcionamento

de

determinado sistema. Para baratear e agilizar a produção de um novo sistema de engenharia são utilizados elementos funcionais prontos para uso, denominados COTS (commercial off-the-shelf), os quais tratam de componentes comerciais reutilizáveis, testados e aceitos pelo mercado – e integráveis com relativa facilidade para a construção de produtos maiores.

ARQUITETURA ORIENTADA A SERVIÇOS - SOA E WEBSERVICES

7

Mesmo que um COTS apresente meios de integração padronizados, essa integração acrescenta alguma complexidade ao sistema, pois o grande desafio no uso de COTS é adequar sua utilização às necessidades do sistema sem alterar o componente em si. Esses componentes, ao apresentarem interfaces padronizadas, podem ser substituídos por outros equivalentes, independentemente de fornecedor, de forma a viabilizar a continuidade do funcionamento do sistema, mesmo que adversidades variadas venham a ocorrer no mercado. Desse modelo surge a ideia básica por trás da interoperabilidade, a qual pode ser definida como a capacidade de elementos heterogêneos se comunicarem, compartilhando dados e complementando funcionalidades. Na área da informática, as atuais arquiteturas de software divididas em camadas, como a MVC (model, view e control), viabilizaram a criação de COTS para cada uma das camadas, como os diversos frameworks existentes.

Fatores considerados na escolha de COTS A

plataforma

Java

sempre

trabalhou

com

esse

conceito,

definindo

especificações para diversas áreas, como criptografia, EJB (Enterprise Java Beans), e muitos outros, nos quais diferentes fornecedores de componentes devem seguir essas especificações de forma a permitir uma fácil permutação entre ambientes distintos. Acompanhe: Quanto à longevidade do componente, existem preocupações acerca da reposição e atualização devido à obsolescência, devendo-se levar em conta a existência de similares e o custo ou esforço efetivo para a substituição do componente no decorrer do ciclo de vida do sistema. Além desses, outros fatores considerados na escolha de COTS, tanto software como hardware, são a confiabilidade, manutenibilidade, eficiência e eficácia.

ARQUITETURA ORIENTADA A SERVIÇOS - SOA E WEBSERVICES

8

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

compartilhamento

de de

integração informações

obtido em

na

bancos

informática de

foi

dados

com

o

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ódigofonte em relação ao fornecedor do banco de dados. Posteriormente, a camada de comunicação com o banco, assim como outros tipos de back-end, foi isolada das demais, definindo-se o que veio a ser chamado de middleware. Essa dependência da ferramenta em relação ao banco em termos de programação, quando eram utilizados componentes específicos de acesso ao invés de um middleware, acaba causando grande dependência do código e alto acoplamento, o que acaba restringindo o uso de um determinado fornecedor de banco ou ao menos dificultando a sua substituição, como era o caso do PHP com MySQL, ou do Clipper com arquivos DBF. Na abordagem atual, de um lado, temos o back-end, representado pelos diversos tipos de bancos de dados; e de outro, o front-end, onde se

ARQUITETURA ORIENTADA A SERVIÇOS - SOA E WEBSERVICES

9

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.

ARQUITETURA ORIENTADA A SERVIÇOS - SOA E WEBSERVICES

10

• Qualquer alteração nos metadados irá trazer consequências para os diversos front-ends. • Se um sistema altera o formato de gravação de um campo, como de real para monetário, os outros sistemas podem parar de funcionar, dependendo do banco de dados utilizado.

Atenção Apesar dos problemas apresentados, o uso de middleware facilitou muito o acesso a bancos de dados e viabilizou um primeiro nível de integração entre sistemas, sendo esse ao nível dos dados.

O termo middleware não se restringe ao uso de banco de dados, podendo tratar da conexão com mensagerias, sistemas de arquivos e outros. Ele será frequentemente utilizado nesta disciplina, sendo melhor detalhado posteriormente.

Integração via protocolo Com o uso extensivo de redes na atualidade, é fácil perceber que o uso de protocolos de comunicação para viabilizar integração entre sistemas é uma realidade, inclusive levando a conceitos como conectividade na definição das características de sistemas operacionais móveis, entre outros. Em termos gerais, o protocolo é a formalização da comunicação e transferência de dados entre dois sistemas computacionais. Ele define formato de chamada e reposta, bem como comandos, tipos de dados aceitos e informações complementares.

ARQUITETURA ORIENTADA A SERVIÇOS - SOA E WEBSERVICES

11

Definido o protocolo, não importa quais tecnologias serão utilizadas para implementar ambos os lados da comunicação, como Java e Dot Net, desde que ambas sejam capazes de acessar a rede e trocar informações no formato especificado. Um protocolo pode ser definido em diversas camadas de rede, segundo o modelo OSI, como:

(Figura representativa das camadas de rede)

Nos dias atuais, é comum a troca de dados entre dispositivos móveis via Bluetooth, ou que esse mesmo dispositivo acesse um servidor HTTP hospedado em ambiente de nuvem. Outro exemplo são os diversos programas clientes de Telnet, criados nas mais diversas linguagens, acessando um servidor Telnet qualquer, sem precisar se preocupar com o fornecedor desse servidor ou o sistema operacional sobre o qual executa. Como o foco maior do mercado são as redes TCP-IP, o uso de Sockets, onde é associado o endereço IP a uma porta que caracteriza a aplicação, tornou-se comum na criação de sistemas remotos; e, com isso, foram definidos serviços genéricos de transferência de dados. ARQUITETURA ORIENTADA A SERVIÇOS - SOA E WEBSERVICES

12

Atenção Com

protocolos

de

comunicação

bem

definidos,

duas

plataformas distintas podem trabalhar em conjunto, resumindo o acoplamento dos aplicativos à simples aceitação do protocolo formal.

Interoperabilidade Os sistemas, em geral, têm evoluído muito, e várias soluções prontas incorporam processos complexos que podem ser disponibilizados para novos desenvolvimentos. Para tal, esses sistemas devem se comunicar com facilidade, segundo o conceito de interoperabilidade. Um sistema interoperável deve permitir acesso a suas funcionalidades segundo padrões de comunicação abertos, aceitos pelo mercado, de forma a tornar transparente, ou quase, o processo de integração. Embora seja antigo o interesse da engenharia de sistemas pelo tema, inicialmente a integração ocorria apenas no nível dos dados, com a definição de formatos e meios de armazenamentos comuns; mas os sistemas foram se tornando mais complexos, novos padrões de comunicação com o meio externo foram definidos, e a interoperabilidade evoluiu para o nível de processos e serviços. O interesse de empresas e órgãos governamentais pelo tema pode ser observado pelo grande número de normas existentes com o objetivo de trazer padronização aos elementos envolvidos nas mais diversas fases do ciclo de vida dos sistemas.

ARQUITETURA ORIENTADA A SERVIÇOS - SOA E WEBSERVICES

13

Um pequeno exemplo de interoperabilidade foi a disponibilização de DDE (Dynamic Data Interchange) e OLE (Object Linked and Embeded) para os ambientes Microsoft Windows, amplamente utilizado em seu pacote Office já há algumas décadas. Com a disponibilização deste tipo de funcionalidade, tornou-se muito comum utilizar uma planilha incorporada a um documento de texto, ou um banco de dados fornecendo para este editor os dados necessários para uma mala direta. Mas a interoperabilidade vai muito além disso, e o elemento principal para viabilizá-la seria a definição de padrões de interface abertos que permitissem a exposição e uso de ferramentas com o mínimo de acoplamento possível.

Atenção Quando uma metodologia ou ferramental tecnológico promete diminuir o acoplamento, isso significa dizer que os componentes e protocolos viabilizam uma independência bem maior por parte de cada participante nas diversas transações.

Padronização de interfaces A busca de interfaces com baixo acoplamento para acesso a serviços e componentes passou por grandes evoluções no decorrer do tempo. Um exemplo de interface padronizada visando à interoperabilidade em termos de software

é

a

evolução

da

tecnologia

OLE,

já

citada

anteriormente,

posteriormente servindo de base para componentes Active X e COM (Component Object Model). As plataformas que viabilizavam a criação desses tipos de componentes precisam se preocupar apenas em atender à interface de programação

ARQUITETURA ORIENTADA A SERVIÇOS - SOA E WEBSERVICES

14

formalmente definida pela Microsoft, a qual trabalha necessariamente com as interfaces IUnknow e IDispatch. Com o uso dessa interface-padrão de programação e ativação de objetos Microsoft, ferramentas como Delphi e Visual Basic passaram a criar objetos intercambiáveis dentro do ambiente Windows. Em termos de redes, inicialmente as interfaces eram baseadas na simples aceitação de protocolos formais, mas posteriormente serviços de rede se especializaram, levando à adoção de padrões para a execução remota de procedimentos. Exemplos de padronização e especialização de interfaces para execução em redes seriam o RPC (Remote Procedure Call) e o RMI (Remote Method Invocation), preocupados com a padronização da chamada a procedimentos e métodos de forma remota. Paralelamente, surgiram sistemas de mensageria que permitiam trabalhar de forma assíncrona, com uso de tecnologias distintas, pelas quais o acoplamento se restringe ao canal de comunicação entre os aplicativos. Os ambientes de objetos distribuídos começaram a ser utilizados, com a padronização dos protocolos de acesso e regras para escrita das interfaces, sem foco em linguagens específicas, pois o objetivo é as plataformas serem acessadas por qualquer um que siga as regras. Apesar de muitas iniciativas terem sido tomadas por diversos fornecedores para a construção de plataformas de objetos distribuídos, a complexidade para a construção desse tipo de ambiente fez com que apenas alguns se destacassem. Alguns exemplos de plataformas de objetos distribuídos amplamente adotadas no mercado: CORBA (Common Object Request Broker Architecture), EJB (Enterprise Java Beans) e DCOM (Distributed Component Object Model). Todas essas plataformas apresentam alguns conceitos comuns e se preocupam em

ARQUITETURA ORIENTADA A SERVIÇOS - SOA E WEBSERVICES

15

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

ARQUITETURA ORIENTADA A SERVIÇOS - SOA E WEBSERVICES

16

computadores pessoais, quando era comum os fabricantes trabalharem com interfaces distintas, até mesmo para evitar a suposta concorrência. Também na área de software essa independência de fornecedores foi bastante almejada, pois, com as possibilidades de integração e definição de interfaces padronizadas, mais fornecedores se animaram com a possibilidade de atingir nichos específicos, reutilizáveis em vários sistemas, como nos casos de bancos de dados e mensagerias. A definição de arquiteturas e metodologias independentes de plataforma ou fornecedores específicos viabiliza a concorrência direta, causando um efeito no mercado de aumento de qualidade e diminuição do custo, estimulando também a melhoria dos meios de produção nas áreas relacionadas a hardware. Um

exemplo

utilizado

para

promover

essa

independência,

já

citado

anteriormente, é o uso de middleware, pois, com a adoção de uma camada intermediária entre front-end e back-end, torna-se praticamente irrelevante o fornecedor escolhido para o back-end. É claro que a qualidade do componente selecionado poderá variar, e o uso em ambientes críticos direcionará a escolha para um grupo menor de fornecedores. As mensagerias com formato padronizado de mensagem também permitem a substituição de seu fornecedor, fazendo com que aspectos de segurança e robustez passem a ser analisados frente ao custo da implantação de uma mensageria específica. Várias soluções de código aberto também passaram a ser utilizadas, o que foi observado muito facilmente na área de banco de dados com a adoção de MySQL por diversas empresas. Em termos de servidores, a padronização dos componentes JEE, bem como CORBA, permite que seja escolhido um entre vários servidores com

ARQUITETURA ORIENTADA A SERVIÇOS - SOA E WEBSERVICES

17

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-0301T134340Z-2764/Publico/Denis%20Cople-Tese.pdf Rowley, K. Understanding Software Interoperability in a Technology-Supported System of Education, https://net.educause.edu/ir/library/pdf/CEM9535.pdf

ARQUITETURA ORIENTADA A SERVIÇOS - SOA E WEBSERVICES

18

Exercícios de fixação Questão 1 Uma prática que se tornou comum na área de engenharia foi a adoção de COTS. Qual das características abaixo NÃO pode ser considerada como referente a um componente deste tipo? a) Apresentam meios de integração padronizados. b) São componentes comerciais reutilizáveis. c) Baseiam-se em padrões abertos de interface. d) Visam proteger tecnologias proprietárias. e) Facilitam a manutenção do sistema, apesar de acrescentarem alguma complexidade em termos de integração. Questão 2 Qual conceito pode ser definido como "a capacidade de elementos heterogêneos se comunicarem, compartilhando dados e complementando funcionalidades "? a) Middleware b) Interoperabilidade c) Front-End d) Back-End e) COTS Questão 3 Um protocolo de rede pode ser considerado como um elemento bastante primário de interoperabilidade, e o mesmo pode ser definido em diversas camadas da rede, segundo o modelo OSI. Assinale a alternativa INCORRETA. a) O protocolo SMTP atua na camada de aplicação. b) O protocolo UDP atua na camada de transporte.

ARQUITETURA ORIENTADA A SERVIÇOS - SOA E WEBSERVICES

19

c) O protocolo TCP/IP atua na camada de transporte. d) O protocolo ICMP atua na camada de rede. e) O protocolo HTTP atua na camada de aplicação. Questão 4 Considere as afirmativas abaixo acerca de middleware: I – Permite transparência com relação ao fabricante do banco de dados. II – O uso de SQL proprietário não diminui a portabilidade com relação ao tipo de banco de dados. III – Faz a mediação entre Front-End e Back-End. IV – Permite acessar bancos de dados legados de tecnologias legadas a partir de novas ferramentas de desenvolvimento. Quantas opções estão corretas? a) Nenhuma b) 1 c) 2 d) 3 e) 4 Questão 5 Existem

preocupações

acerca

da

reposição

e

atualização

devido

a

obsolescência, devendo ser levado em conta a existência de similares e o custo ou esforço efetivo para a substituição do mesmo no decorrer do ciclo de vida do sistema. Para satisfazer a este tipo de preocupação, qual fator deve ser considerado na escolha de COTS? a) Eficiência b) Eficácia c) Longevidade d) Confiabilidade e) Manutenibilidade Questão 6

ARQUITETURA ORIENTADA A SERVIÇOS - SOA E WEBSERVICES

20

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

ARQUITETURA ORIENTADA A SERVIÇOS - SOA E WEBSERVICES

21

c) RMI d) CORBA e) Banco de dados Questão 10 Qual a sintaxe que trouxe uma vertiginosa evolução dos modelos de interoperabilidade, sendo de grande utilização nas arquiteturas orientadas a serviço da atualidade? a) Java b) HTML c) XML d) Delphi e) C++

ARQUITETURA ORIENTADA A SERVIÇOS - SOA E WEBSERVICES

22

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

compartilhando

dados

de e

elementos

heterogêneos

complementando

se

funcionalidades.

comunicarem, Quanto

ao

Middleware e COTS, estes viabilizam a interoperabilidade em determinados contextos restritos. Questão 3 - C Justificativa: Esta é uma confusão comum em diversos blogs e discussões acerca de redes. Em verdade são dois protocolos: o TCP atuando na camada de transporte, e o IP atuando na camada de rede. Não existe o protocolo TCP/IP. Questão 4 - D Justificativa: A opção II está incorreta, pois para manter a portabilidade de banco de dados deve ser utilizado apenas o SQL ANSI. As demais opções estão corretas. Questão 5 - C Justificativa: O fator que satisfaz à necessidade apresentada é a longevidade, pois eficiência e eficácia referem-se às características funcionais próprias do sistema, e confiabilidade e manutenibilidade referem-se a características de manutenção pontuais dos COTS, sem uma visão de atualização e reposição no decorrer do tempo.

ARQUITETURA ORIENTADA A SERVIÇOS - SOA E WEBSERVICES

23

Questão 6 - E Justificativa: Enquanto as demais opções permitem o uso de linguagens de programação distintas na implementação dos componentes, o BDE trata de um middleware exclusivo do Delphi para acesso a banco de dados. Questão 7 - C Justificativa: Quem é voltado exclusivamente para integração entre Delphi e banco de dados é o BDE. Quanto ao OLE e DDE, estas são tecnologias da Microsoft, que executam em ambiente Windows, e são muito utilizadas na integração entre os softwares do pacote Microsoft Office. Quanto ao protocolo SOAP, ele é baseado em sintaxe XML. Questão 8 - B Justificativa: Os três são exemplos de objetos distribuídos (software), sendo que o CORBA não é tecnologia proprietária. Nenhum dos exemplos define uma gramática XML e, por fim, não são sistemas operacionais, como seria o caso do Windows e do Linux. Questão 9 - A Justificativa: O conceito exposto é a própria definição de sistemas de mensageria, além de ser a única das cinco tecnologias citadas que viabiliza nativamente o comportamento assíncrono. Questão 10 - C Justificativa: As arquiteturas orientadas a serviço da atualidade trabalham muito com a sintaxe XML, particularmente com o uso do mesmo através do protocolo SOAP. Como características fortes da sintaxe podemos ressaltar a facilidade de manuseio por qualquer linguagem e a transparência na transmissão através de firewalls.

ARQUITETURA ORIENTADA A SERVIÇOS - SOA E WEBSERVICES

24

Introdução Com a grande diversidade de sistemas e fornecedores de componentes, a interoperabilidade torna-se um diferencial para as ferramentas, e algumas arquiteturas passam a trabalhar visando a esse princípio. Essa aula irá apresentar uma arquitetura baseada em interoperabilidade utilizada na área de simulações militares, a qual é denominada HLA (high level architecture), bem como trazer conhecimentos acerca do uso de mensagerias. Estes são dois exemplos de arquiteturas voltadas para reuso: interoperabilidade e baixo acoplamento. Objetivo: 1. Compreender os conceitos gerais e características da HLA; 2. Entender o funcionamento de mensagerias e sua utilização com Java.

ARQUITETURA ORIENTADA A SERVIÇOS - SOA E WEBSERVICES

25

Conteúdo

High level architecture A área de simuladores sempre apresentou grande complexidade. E muitas soluções para os mesmos problemas seguiam caminhos diferentes, impedindo que tais soluções trabalhassem em conjunto. 1- Muitas simulações complexas e de grande porte acabam por envolver várias simulações individuais menores. 2 - As simulações menores eram construídas de forma heterogênea, tanto em termos do tipo de simulação quanto em relação às funcionalidades dos componentes. 3 - Muitos componentes da simulação já existiam, porém não eram integráveis. 4 - Recriar um componente de simulação, além de ser caro, representa um risco maior em termos de testes e estabilidade. Essa não é uma preocupação nova. Como pode ser observado, a ausência de um ambiente interoperável e de componentes reutilizáveis acaba por encarecer a construção de um sistema de simulação, bem como demandar mais tempo na implementação. Além disso, se fossem utilizados COTS, esses já teriam passado por várias fases de teste, diminuindo o risco da implementação final. Partindo dessas necessidades, e após diversas iniciativas de integração e padronização de interfaces na área de simulação militares, foi definido o HLA (high level architecture): 

Um

framework

genérico

com

a

finalidade

de

melhorar

a

interoperabilidade e reuso de componentes de simulação. 

Criado pelo Defense Modeling and Simulation Office (DMSO).



Desenvolvido inicialmente para o Departamento de Defesa dos Estados Unidos (DoD).

ARQUITETURA ORIENTADA A SERVIÇOS - SOA E WEBSERVICES

26



Tornou-se um padrão no ano de 2000 (IEEE Standard 1516-2000).

A adoção de HLA promove o reuso de componentes de simulação que podem vir a ser utilizados em diferentes cenários e sistemas ao longo de sua vida útil. • Permite agrupar simulações compostas de múltiplos componentes de simulação; • Integra simulações distribuídas através de diferentes plataformas de software e hardware heterogêneo; • Reutiliza sistemas sem mudanças significantes de código ou custo maior de desenvolvimento; • Combina componentes de simulação com diversos modelos computacionais e representações formais.

HLA e RTI Termos e definições do HLA:

ARQUITETURA ORIENTADA A SERVIÇOS - SOA E WEBSERVICES

27



Federate é uma aplicação com suporte a HLA que pode participar de uma simulação nesse ambiente.



Federation é a declaração entre federates que definem como e o que será simulado.



Federation execution trata de uma instância de um federation em execução, ou seja, a execução da simulação em si.

Dentro da arquitetura do HLA é definida uma infraestrutura de execução, ou RTI (run-time infrastructure), que trata basicamente de um framework com as seguintes características: • Camada de software que fornece serviços comuns aos federates. • A especificação do RTI define as interfaces que os federates precisam acessar para obter serviços e interagir com outros federates. • Essa especificação também define qual interface os federates devem expor para que sejam reconhecidos pelos serviços e por outros federates. • Trabalha com tecnologias de simulação legadas, como DIS e ALSP. • Promove uma comunicação eficiente entre federates. • Separa os conceitos de simulação e comunicação. • Independente de linguagem ou plataforma. Os principais componentes apresentados pela RTI são: • Gestão de federation, que controla as atividades de cada federation durante a execução. • Gestão de declarações, que controla o modelo de publicação e assinatura para troca de informações. • Gestão de objetos, controlando todo o ciclo de vida e troca de mensagens entre esses objetos.

ARQUITETURA ORIENTADA A SERVIÇOS - SOA E WEBSERVICES

28

• 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

- Inicialização e término da execução de Federations - Joining and resigning of federates Gestão de Federation

- Pausa e reinício da execução do Federation - Persistência (armazenagem e recuperação) de Federation em execução - Publicação do objeto e classes de interação - Resgate de classes de interação

Gestão de declarações

- Resgate de atributos do objeto - Controle de alterações - Controle de interações

ARQUITETURA ORIENTADA A SERVIÇOS - SOA E WEBSERVICES

29

- Registro e localização de objetos - Alteração e exposição de atributos de objetos Gestão de objetos

- Envio e recebimento de mensagens de interação - Remoção de objetos - Manage transport/ordering - Assume/divest attribute ownership

Gestão de responsáveis

- Acquire/release attribute ownership - Notification of ownership changes (Federation) - Sincronização conservativa - Sincronização otimista - Métodos híbridos de sincronização - Avanço de tempo - Controle de tempo real

Gestão de tempo (Federate) - Requisição de avanço de tempo - Notificação de avanço concedido - Requisição do próximo evento - Notificação de evento concedido - Gerenciamento da fila de requisições

ARQUITETURA ORIENTADA A SERVIÇOS - SOA E WEBSERVICES

30

- Definição da área de update na publicação Gestão de dados

- Definição da área de interesse pelo participante

distribuídos

- Gestão das áreas de roteamento (interseções) - Transformação de nome para handle - Transformação de handle para nome Serviços de apoio

- Gestão do sistema de avisos - Manipulação de regiões - RTI start-up e shutdown

A figura a seguir mostra resumidamente o funcionamento de uma federation.

(Figura ilustrativa do funcionamento de um federation.)

ARQUITETURA ORIENTADA A SERVIÇOS - SOA E WEBSERVICES

31

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, observandose as soluções apresentadas pela HLA, é fácil perceber como muitos dos serviços de gestão do RTI estão presentes nas arquiteturas de objetos distribuídas e orientadas a serviços.

Mensagerias Uma solução para a integração de sistemas complexos com baixíssimo acoplamento é o uso de mensagerias. Conheça, a seguir, exemplos de mensagerias comumente encontradas no mercado.

Podemos ter sistemas desenvolvidos em diferentes tecnologias, como Java e C#, cada uma com sua biblioteca de middleware para acesso à mensageria, nesse caso denominado MOM (message oriented middleware), trocando mensagens através dessa mensageria, inclusive de forma assíncrona. O princípio de escrita e leitura assíncrona é muito comum nas diversas tecnologias de interação social, como e-mails, mensagens em redes sociais, mensagens em ambientes móveis, entre muitos outros exemplos. Basicamente,

ARQUITETURA ORIENTADA A SERVIÇOS - SOA E WEBSERVICES

32

trata-se de uma arquitetura peer-to-peer com serviço centralizado de repasse de mensagens recebidas e enviadas, serviços esse que administra canais registrados acessíveis tanto aos clientes quanto aos servidores.

Um exemplo do uso de mensagerias no dia a dia de qualquer brasileiro é o processamento de DOCs e TEDs do sistema bancário. O que recebemos ao solicitar esse tipo de transação é um mero comprovante da solicitação em si, que é enviada para uma mensageria, sendo processada algum tempo depois pelo banco alvo, sem obrigar o usuário a esperar por esse processamento, ou, em termos técnicos, atuando de forma assíncrona. Existem dois modelos de comunicação disponíveis nesse ambiente: fila e tópico.

Fila No modelo de fila, existem muitos destinatários e apenas um receptor, o qual pode ou não estar ativo no momento do envio. O receptor retira da fila a mensagem, processa-a e envia um sinal para a mensageria informando que já houve o consumo (acknowledgement). A fila retém a mensagem até que ela seja consumida, segundo uma ordenação FIFO (a primeira a entrar é a primeira a sair).

ARQUITETURA ORIENTADA A SERVIÇOS - SOA E WEBSERVICES

33

(figura representativa de um modelo de Fila)

Tópicos No modelo de tópicos, podem ocorrer vários emissores e vários receptores simultaneamente. Esse modelo também é denominado publish-subscribe. As mensagens são enviadas a um canal (tópico), de onde os assinantes poderão retirá-las. Nesse modelo, é necessário um objeto ouvinte (message listener) para avisar que há nova mensagem no canal.

ARQUITETURA ORIENTADA A SERVIÇOS - SOA E WEBSERVICES

34

(figura representativa de um modelo de Tópicos)

Utilização de mensagerias O uso de mensagens é indicado em situações específicas. Quando o elemento principal da comunicação é o formato da mensagem, e não interfaces de programação. Quando não é possível prever a disponibilidade dos componentes de ambos os lados, receptor ou emissor. Quando é preciso suportar comunicação assíncrona, ou seja, o emissor envia a informação, mesmo que o receptor não esteja ativo, e não bloqueia suas operações.

ARQUITETURA ORIENTADA A SERVIÇOS - SOA E WEBSERVICES

35

Atenção É muito comum a adoção de mensagerias em processos B2B (business to business), ou seja, na comunicação entre sistemas de empresas distintas, como é o caso das instituições bancárias brasileiras.

Como as mensagerias permitem um melhor controle de acesso, acabam formando um canal de comunicação privado entre as empresas, aumentando também a segurança da comunicação entre elas.

Na linguagem Java, o MOM é acessado pelo Java Message Service (JMS), uma biblioteca que consiste basicamente de interfaces a serem implementadas pelo fabricante do MOM, assim como ocorre com o JDBC.

Message driven bean Na arquitetura JEE, existe um componente especializado no tratamento de mensagens, o qual é denominado MDB (message driven bean), e que faz uso do JMS para acesso a diferentes mensagerias. Os componentes do tipo MDB são EJBs (enterprise java beans), e, como demais componentes dessa arquitetura, atualmente, podem ser criados com o uso de simples código anotado Java.

ARQUITETURA ORIENTADA A SERVIÇOS - SOA E WEBSERVICES

36

A anotação @MessageDriven define a classe como um MDB, configurando recurso acessado na mensageria, bem como o tipo de destino (fila ou tópico). A classe, por sua vez, deve implementar a interface MessageListener, de forma a tratar as mensagens recebidas em seu método onMessage. Um componente do tipo MDB nunca pode ser acessado diretamente, pois sua finalidade é a de tratar as mensagens recebidas a partir da mensageria. Para ativá-lo, o que se faz necessário é a postagem de uma mensagem na fila ou tópico assistido por esse componente. A arquitetura do JEE e a caracterização dos demais EJBs serão discutidas posteriormente nessa disciplina.

(Figura representativa Java EE Server)

ARQUITETURA ORIENTADA A SERVIÇOS - SOA E WEBSERVICES

37

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á :::: Ex.: Para a mensagem 12.5::21.3::+ será gravado no log 12.5 + 21.3 = 33.8

Referências Dahmann, J. Fujimoto, R. Weatherly, R. The Department of Defense High Level Architecture http://www.cc.gatech.edu/computing/pads/PAPERS/DOD_High_Lev el_Arch.pdf Saudate, A. SOA aplicado: Integrando com web services e além, Editora Casa do Código, 2012.

ARQUITETURA ORIENTADA A SERVIÇOS - SOA E WEBSERVICES

38

Exercícios de fixação Questão 1 O que vem a ser RTI para a High Level Architecture? a) Uma aplicação com suporte a HLA e que pode participar de simulações neste ambiente. b) Uma simulação em execução. c) Apenas um temporizador para as diversas simulações. d) Uma máquina virtual para suportar aplicações Java. e) Basicamente um framework que garante uma infraestrutura de execução das simulações heterogêneas. Questão 2 Quem foi a entidade responsável pela criação do HLA? a) Microsoft b) MEC c) Oracle d) FAB e) DMSO Questão 3 Com a Gestão do tempo, o RTI: a) Controla o modelo de publicação e assinatura para troca de informações. b) Permite a transmissão eficiente de dados entre Federates. c) Coordena a linha de tempo de cada Federate dentro do eixo de tempo do Federation, garantindo a preservação de causa e ordenação. d) Controla todo o ciclo de vida e troca de mensagens entre os objetos. e) Controla as atividades de cada Federation durante a execução.

ARQUITETURA ORIENTADA A SERVIÇOS - SOA E WEBSERVICES

39

Questão 4 O que vem a ser Federate para a High Level Architecture? a) Uma aplicação com suporte a HLA e que pode participar de simulações neste ambiente. b) Uma simulação em execução. c) Apenas um temporizador para as diversas simulações. d) Uma máquina virtual para suportar aplicações Java. e) Basicamente um framework que garante uma infraestrutura de execução das simulações heterogêneas. Questão 5 No ano de 2000 a High Level Architecture foi transformada em um padrão (standard). Qual foi a entidade normatizadora? a) DMSO b) DoD c) W3C d) SSL e) IEEE Questão 6 Qual das opções abaixo NÃO é um exemplo de mensageria? a) JBoss MQ b) IBM MQ Series c) IPlanet MQ d) Bea Web Logic e) QueueSender Questão 7 Onde é imprescindível um objeto ouvinte (MessageListener) para avisar que existe uma mensagem no canal da mensageria? a) Envio do modelo de fila

ARQUITETURA ORIENTADA A SERVIÇOS - SOA E WEBSERVICES

40

b) Recepção do modelo de fila c) Envio do modelo de tópico d) Recepção do modelo de tópico e) Preparação prévia da mensagem para envio Questão 8 Quando o uso de mensagerias NÃO é indicado? a) Quando o elemento principal da comunicação é o formato da mensagem b) Quando existe a necessidade de bloquear o cliente durante a transação c) Quando não é possível prever a disponibilidade dos componentes d) Quando é preciso suportar comunicação assíncrona e) Quando é necessário enviar a mensagem, mesmo que o receptor não esteja ativo Questão 9 Podemos ter sistemas desenvolvidos em diferentes tecnologias, como Java e C#, cada uma com sua biblioteca de middleware para acesso à mensageria, nesse caso denominado: a) MOM b) RPC c) RMI d) JDBC e) EJB Questão 10 Dentro do ambiente JEE, qual o nome do componente responsável por receber as mensagens advindas de uma mensageria? a) SessionBean b) Stateless c) MDB d) Stateful e) EntityBean

ARQUITETURA ORIENTADA A SERVIÇOS - SOA E WEBSERVICES

41

ARQUITETURA ORIENTADA A SERVIÇOS - SOA E WEBSERVICES

42

Aula 2 Exercícios de fixação Questão 1 - E Justificativa: A sigla RTI significa Infraestrutura de tempo de execução, e cuida do gerenciamento das Federates, Federation e Federation Execution, entre outros elementos. Questão 2 - E Justificativa: Quem criou o HLA foi o Defense Modeling and Simulation Office (DMSO). Questão 3 - C Justificativa: Os componentes responsáveis pelas funções citadas nestas opções são: –

Gestão de declarações, que controla o modelo de publicação e assinatura

para troca de informações; –

Gestão de dados distribuídos, com a transmissão eficiente de dados

entre Federates; –

Gestão de tempo, o qual coordena a linha de tempo de cada Federate

dentro do eixo de tempo do Federation, garantindo a preservação de causa e ordenação. –

Gestão de objetos, controlando todo o ciclo de vida e troca de

mensagens entre estes objetos; –

Gestão de Federation, que controla as atividades de cada Federation

durante a execução. Questão 4 - A Justificativa: Uma aplicação compatível com o ambiente HLA é denominada Federate.

ARQUITETURA ORIENTADA A SERVIÇOS - SOA E WEBSERVICES

43

Questão 5 - E Justificativa: Inicialmente a HLA foi normatizada pelo IEEE Standard 1516-2000. Questão 6 - E Justificativa: A única opção que não trata de uma mensageria comercial é o QueueSender. Este é, na verdade, o componente Java necessário para enviar uma mensagem no modelo de fila sem uso de EJBs. Questão 7 - D Justificativa:

No

modelo

de

tópico

é

necessário

um

objeto

ouvinte

(MessageListener) para avisar que há nova mensagem no canal, de forma que os assinantes possam recebê-la. Questão 8 - B Justificativa: O uso de mensagerias é indicado em todos estes casos, menos quando há necessidade de bloquear o cliente, isso porque o funcionamento é justamente o oposto, sem bloqueio do cliente, o que viabiliza o comportamento assíncrono. Questão 9 - A Justificativa: O middleware para acesso a mensagerias é denominado MOM, ou Message Oriented Middleware. As opções RPC e RMI referem-se a sistemas de processamento distribuído, enquanto JDBC é o middleware para acesso a banco de dados do Java, e o EJB um componente corporativo da plataforma JEE. Questão 10 - C Justificativa: O componente responsável pela recepção das mensagens é o Message Driven Bean, definido pela anotação @MessageDriven, e que precisa implementar a interface MessageListener.

ARQUITETURA ORIENTADA A SERVIÇOS - SOA E WEBSERVICES

44

Introdução Uma evolução natural da programação foi a utilização de processamento paralelo para a resolução de problemas complexos. A distribuição de processamento também é utilizada com tal finalidade, ou em situações nas quais os participantes de uma transação não se encontram fisicamente no mesmo local. Esta aula visa elucidar conceitos como processamento paralelo e distribuído, além de descrever tecnologias de grande aceitação na implementação de sistemas distribuídos, como RPC e RMI. Objetivo: 1. Compreender o processamento distribuído e uso do RPC; 2. Conhecer a tecnologia Java RMI.

ARQUITETURA ORIENTADA A SERVIÇOS - SOA E WEBSERVICES

45

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

aproveitamento

processamento do

tempo

de

paralelo CPU,

sempre

visaram

particularmente

ao

quando

melhor 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

ARQUITETURA ORIENTADA A SERVIÇOS - SOA E WEBSERVICES

46

método run, e quando há necessidade de sincronização utiliza-se a palavrachave synchronized.

(imagem representativa do método run)

ARQUITETURA ORIENTADA A SERVIÇOS - SOA E WEBSERVICES

47

Processamento distribuído A distribuição de processamento também pode ocorrer ao longo de uma rede, com diferentes processos sendo executados em máquinas remotas, segundo protocolos específicos de comunicação. O termo DCE (Distributed Computing Environment) é comumente utilizado para definir esse tipo de ambiente, onde vários componentes de software, como serviços de diretórios, gestores de segurança, sistemas de objetos distribuídos, entre vários outros, trabalham em conjunto para a construção de complexos sistemas corporativos. Dentro de uma rede TCP-IP, a definição de um serviço distribuído de forma mais simples envolve a construção de um servidor, normalmente trabalhando com paralelismo, que seja capaz de escutar uma porta específica destinada ao serviço oferecido, e clientes capazes de se comunicar com esse servidor segundo um protocolo previamente estabelecido. Um código em linguagem Java de exemplo para a criação de um sistema cliente-servidor com uso de Socket. Embora qualquer sistema cliente-servidor possa atuar dessa forma, algumas arquiteturas próprias foram definidas para a formalização dos serviços distribuídos, como o RPC e o RMI.

ARQUITETURA ORIENTADA A SERVIÇOS - SOA E WEBSERVICES

48

ARQUITETURA ORIENTADA A SERVIÇOS - SOA E WEBSERVICES

49

(imagem representativa de um código em linguagem Java)

RPC (Remote Procedure Call) A chamada remota de procedimento (RPC) trata de um modelo de comunicação entre processos que viabiliza a chamada de um procedimento em outro espaço de endereçamento, normalmente em outro computador da rede, sem que o programador tenha que se preocupar com detalhes dessa interação remota, assemelhando-se a chamadas locais em termos de código. Com isso, o uso de RPC simplifica a criação de sistemas distribuídos deixando a comunicação transparente para o programador. Essa é uma ideia antiga, datando de 1976, quando foi descrita na RFC 707. Foi utilizada de maneira comercial inicialmente pela Xerox, em 1981, sendo a primeira implementação popular efetuada para UNIX com o Sun RPC, usado como base para o NFS (Network File System). Várias extensões da comunicação remota para ambientes de objetos distribuídos,

como

CORBA

e

DCOM,

são

baseadas

em

diferentes

implementações do RPC. As ferramentas para criação de aplicativos RPC cuidam da geração dos stubs para garantir essa transparência. ARQUITETURA ORIENTADA A SERVIÇOS - SOA E WEBSERVICES

50

A ideia fundamental é a de que o servidor exporta apenas a interface de procedimentos e funções, da mesma forma que ocorreria com uma API ou biblioteca. O programa cliente faz a chamada ao procedimento remoto, com a passagem dos parâmetros necessários, e recebe a resposta, como se estivesse chamando um simples método local. O par de stubs faz a transformação de chamadas e respostas nas mensagens necessárias para a comunicação em rede. Em termos do servidor, esse elemento responsável pela interceptação das chamadas é comumente denominado skeleton, e deve receber a chamada, ativar o componente de software responsável pelo processamento do pedido, e retornar com a resposta solicitada. Com todas essas características, o único vínculo real entre o código do cliente e o do servidor é a interface de exposição de serviços, a qual segue uma sintaxe bastante simples. Um exemplo de sistema com uso de RPC na sintaxe C, bem como a interface de exposição dos serviços:

/* addsub.x : definição da interface */ #define PROGRAM_NUMBER 12345678 #define VERSION_NUMBER 1

/* tipo de dado que será passado aos procedimentos remotos */

struct operands { int x; int y;

ARQUITETURA ORIENTADA A SERVIÇOS - SOA E WEBSERVICES

51

};

/* 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 #include "addsub.h" /* implementação da função add */ int * add_1_svc (operands *argp, struct svc_req *rqstp) { static int result; printf ("Recebi chamado: add %d %d\n", argp->x, argp->y); result = argp->x + argp->y; return (&result); } /* implementação da função sub */

ARQUITETURA ORIENTADA A SERVIÇOS - SOA E WEBSERVICES

52

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 #include "addsub.h" /* função que chama a RPC add_1 */ int add (CLIENT *clnt, int x, int y) { operands ops; int *result; /* junta os parâmetros em um struct */ ops.x = x; ops.y = y; /* chama a função remota */ result = add_1 (&ops,clnt); if (result == NULL) { printf ("Problemas ao chamar a função remota\n"); exit (1); } return (*result); } int main( int argc, char *argv[]) { CLIENT *clnt; int x,y;

ARQUITETURA ORIENTADA A SERVIÇOS - SOA E WEBSERVICES

53

/* 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.

ARQUITETURA ORIENTADA A SERVIÇOS - SOA E WEBSERVICES

54

(imagem representativa da tecnologia RMI)

O passo inicial para o desenvolvimento de um sistema com uso de RMI é a definição da interface remota, o que equivaleria à definição da IDL utilizada no RPC, porém restrita ao universo Java.

Essa interface deverá ser descendente da interface Remote e cada método dela deverá considerar a ocorrência da exceção RemoteException, como pode ser observado no exemplo seguinte:

ARQUITETURA ORIENTADA A SERVIÇOS - SOA E WEBSERVICES

55

Criada a interface, deve ser definido um objeto servidor que a implementa, criando assim os métodos do serviço. Esse objeto também deve ser descendente de UnicastRemoteObject. Um objeto da classe CalcRemote deve ser instanciado e registrado pelo programa servidor, ficando disponível para os clientes através da escuta efetuada pelo RMI Registry.

ARQUITETURA ORIENTADA A SERVIÇOS - SOA E WEBSERVICES

56

Com relação ao cliente, este deverá localizar o objeto servidor através do protocolo gerenciado pelo RMI Registry, efetuando a chamada aos métodos remotos, segundo o que foi definido em ICalcRemote. O uso de RMI permite a definição de um DCE de grande simplicidade de uso para a linguagem Java, permitindo a passagem de informações através de objetos serializáveis mais complexos, segundo um padrão Proxy, diminuindo muito o esforço de programação. No entanto, quando são tratados os sistemas corporativos, vários requisitos, como transações, pooling e autenticação, podem não ser oferecidos de forma simples pelo RMI. Para satisfazer a esse tipo de necessidade são utilizados ambientes de objetos distribuídos.

Marshalling e Unmarshalling Um conceito comum em termos de programação orientada a objetos é a serialização de objetos. A serialização é a transformação de dados em geral, que estejam em memória, para um formato adequado em array de bytes, pronto para armazenagem ou transferência do mesmo.

ARQUITETURA ORIENTADA A SERVIÇOS - SOA E WEBSERVICES

57

Em outro momento o processo inverso (desserialização) pode ser efetuado, partindo do array de bytes e montando a estrutura novamente em memória, claro que ocupando locais diferentes da mesma. Em termos de comunicação remota, um conceito similar é o de Marshalling e Unmarshalling, pois trata da transformação dos dados estruturados segundo uma determinada tecnologia, como Java ou C#, em formato compatível com as mensagens que são trafegadas entre os stubs (Marshalling), bem como o processo inverso, para a recuperação dos dados a partir da mensagem (Unmarshalling), lembrando que nas duas pontas as linguagens podem ser distintas.

Serviços de nomes e diretórios A chamada remota de procedimento (RPC) trata de um modelo de comunicação entre processos que viabiliza a chamada de um procedimento em outro espaço de endereçamento, normalmente em outro computador da rede, sem que o programador tenha que se preocupar com detalhes dessa interação remota, assemelhando-se a chamadas locais em termos de código. 

Associam nomes a recursos computacionais em rede;



Funcionam como “diretórios” compartilhados;



Envolvem funções de localização e registro de elementos;



Permitem armazenar objetos, certificados digitais e outros elementos serializáveis.

Amplamente utilizados pelas instituições bancárias, DAP (Directory Access Protocol) e LDAP (Lightweight Directory Access Protocol) são exemplos desse tipo de serviço. No caso da tecnologia Java, as ações de registro e localização são feitas pelo JNDI (Java Naming and Directory Interface), o qual apresenta

ARQUITETURA ORIENTADA A SERVIÇOS - SOA E WEBSERVICES

58

uma interface única entre os diversos serviços de diretório, gerenciando inclusive o acesso a recursos como RMI, CORBA, DAP, LDAP e JEE.

Atividade proposta Implemente um serviço RMI que receba o valor de dois catetos de um triângulo retângulo e retorne o valor da hipotenusa. Parâmetros de entrada: double cateto1, double cateto2 Retorno: double Cálculo: hipotenusa = Math.sqrt(Math.pow(cateto1,2)+Math.pow(cateto2,2))

Referências Silva, F. Sistemas Distribuídos: Conceitos e Projeto RPC e RMI, UFMA, 2013 http://www.deinf.ufma.br/~fssilva/graduacao/sd/aulas/rpc_rmi.pdf Grosso, W. Java RMI (Java Series), O’Reilly, 2001.

ARQUITETURA ORIENTADA A SERVIÇOS - SOA E WEBSERVICES

59

Exercícios de fixação Questão 1 Quando trabalhamos com processamento paralelo, um problema comum é a utilização de recursos compartilhados que podem ser lidos ou escritos de forma errônea

devido

à

preempção.

Para

resolver

isso

deve

ocorrer

um

sequenciamento no acesso ao recurso, o que é obtido no Java com o uso da palavra reservada: a) static b) volatile c) synchronized d) abstract e) final Questão 2 Uma classe ServerSocket deve escutar uma porta especificada e aceitar conexões solicitadas pelos clientes, repassando as mesmas para objetos Socket locais, o que define o circuito virtual entre cliente e servidor. Qual o método utilizado para aceitar uma conexão? a) start b) accept c) getInputStream d) getOutputStream e) close Questão 3 A utilização de RPC viabiliza a construção de sistemas de processamento distribuído com um formato de comunicação transparente para o programador. Quem permite esta transparência são os _______________ definidos para o padrão Proxy. a) senders b) idles c) clients

ARQUITETURA ORIENTADA A SERVIÇOS - SOA E WEBSERVICES

60

d) stubs e) publishers Questão 4 Na arquitetura do RPC, o elemento responsável por tratar as chamadas no servidor é denominado: a) IDL b) stub c) skeleton d) Socket e) ServerSocket Questão 5 O elemento na arquitetura do RPC que permite a geração automática de todo o aparato de comunicação em rede, de forma automatizada, por ferramentas como o rpcgen é: a) IDL b) stub c) skeleton d) Socket e) ServerSocket Questão 6 Em sistemas de processamento distribuído ocorre a necessidade de registrar e localizar componentes disponibilizados remotamente. O componente de software responsável por executar esta função seria: a) Interface de Descrição de Serviços b) Serviço de Nomes e Diretórios c) Temporizador d) Protocolo de Comunicação e) Gerenciador do Banco de Dados

ARQUITETURA ORIENTADA A SERVIÇOS - SOA E WEBSERVICES

61

Questão 7 A transformação dos dados estruturados segundo uma determinada tecnologia, como Java ou C#, em formato compatível com as mensagens que são trafegadas entre os stubs é denominada: a) serialização b) unmarshalling c) marshalling d) de-serialização e) vetorização Questão 8 Em termos de RMI a descrição dos serviços é feita na própria linguagem Java através de uma interface descendente de: a) Remote b) Runnable c) MessageListener d) Serializable e) CommandListener Questão 9 Considere as afirmativas abaixo: I – Os métodos expostos pela interface remota do RMI devem considerar a ocorrência da exceção RemoteException. II – Criada a interface, deve ser definido uma classe que implementa a mesma e seja descendente de UnicastRemoteObject. III – Os passos I e II são necessários e suficientes para a criação de um servidor RMI. Quais as afirmativas corretas? a) Todas estão corretas b) Apenas a I está correta c) Apenas a II está correta d) As alternativas I e II estão corretas

ARQUITETURA ORIENTADA A SERVIÇOS - SOA E WEBSERVICES

62

e) Nenhuma está correta Questão 10 No ambiente Java os serviços de nomes e diretórios são acessados através de: a) DAP b) LDAP c) DNS d) JEE e) JNDI

ARQUITETURA ORIENTADA A SERVIÇOS - SOA E WEBSERVICES

63

Aula 3 Exercícios de fixação Questão 1 - C Justificativa: Em linguagem Java uma tarefa independente pode ser definida pela extensão da classe Thread ou pela implementação da interface Runnable, e quando há necessidade de sincronização utiliza-se a palavra-chave synchronized. Questão 2 - B Justificativa: Os métodos getInputStream, getOutputStream e close pertencem à classe Socket, enquanto start inicia uma Thread. O método accept pertence ao ServerSocket e serve para receber uma conexão na porta especificada na inicialização do mesmo. Questão 3 - D Justificativa: As ferramentas para criação de aplicativos RPC cuidam da geração dos stubs para garantir a transparência da comunicação em rede. O par de stubs faz a transformação de chamadas e respostas nas mensagens necessárias. Questão 4 - C Justificativa: Em termos do servidor, o 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. Questão 5 - A Justificativa: A utilização de Socket e ServerSocket de forma plana não constituiria um sistema RPC. Nas arquiteturas do tipo RPC deve haver uma IDL

ARQUITETURA ORIENTADA A SERVIÇOS - SOA E WEBSERVICES

64

(Interface Definition Language) que permita a aplicativos como o rpcgen gerar os stubs para a comunicação com o skeleton do servidor. Questão 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 localização externa ao programa que fornece este recurso, é comum o uso de serviços de nomes e diretórios. Questão 7 - C Justificativa: A transformação dos dados para o formato de envio é denominada marshalling, enquanto o processo inverso, na recepção, é denominado unmarshalling. Questão 8 - A Justificativa: 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. Esta interface deverá ser descendente da interface Remote. Questão 9 - D Justificativa: A alternativa III está incorreta, pois seria ainda necessário criar um aplicativo (main) que registre uma instância da classe criada em II, bem como o rmiregistry deverá estar em execução para que este aplicativo consiga também executar. Questão 10 - E Justificativa: No caso do Java, as ações de registro e localização são feitas pelo JNDI, 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.

ARQUITETURA ORIENTADA A SERVIÇOS - SOA E WEBSERVICES

65

Introdução Com as necessidades corporativas em termos de processamento, cooperação, transações e segurança, começam a aparecer diversas plataformas de objetos distribuídos. 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 distribuídos com acesso irrestrito às tecnologias Java, e que mantém compatibilidade com tecnologias legadas através de uma camada de comunicação compatível com CORBA. Objetivo: 1. Compreendeu os objetos distribuídos e uso de CORBA; 2. Entendeu a arquitetura do JEE e sua interoperabilidade com CORBA.

ARQUITETURA ORIENTADA A SERVIÇOS - SOA E WEBSERVICES

66

Conteúdo Objetos distribuídos Em termos de orientação a objetos, uma Interface define um conjunto bemdefinido de métodos públicos que viabilizam o acesso e uso externo. Uma referência a um objeto trata-se de um ponteiro de memória, onde o acesso ao estado do objeto é feito através de sua interface, que deve ser a única parte visível do objeto. A forma como a interface é implementada não 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 estão em máquinas distintas e oferecem suas interfaces para acesso através da rede, isso define a base do conceito de objetos distribuídos. Características de objetos distribuídos: • Interagem através da rede; • Atuam de forma colaborativa; • Apenas a interface do objeto pode ser acessada e de forma remota; • A interface define os serviços oferecidos; • Para referenciar o objeto é necessário o endereço de rede; • Comunicam-se segundo o padrão de desenvolvimento Proxy. As soluções que implementam objetos distribuídos geralmente têm uma estrutura que consiste de: • Serviço de registro de objetos: serviço que mapeia um nome a um objeto para que possa ser localizado pelas aplicações que querem usar seus serviços;

ARQUITETURA ORIENTADA A SERVIÇOS - SOA E WEBSERVICES

67

• Interface de comunicação: documento ou classe que declara a interface (métodos, parâmetros, tipos de retorno etc.) que podem ser chamados no objeto. É o principal instrumento de interoperabilidade; • Infraestrutura de comunicação: barramento que utiliza um protocolo comum, stubs que encapsulam código de rede do cliente e skeletons que encapsulam servidores; • Formato de dados comuns usado na comunicação. Alguns exemplos de arquiteturas de objetos distribuídos são: •

CORBA,

tecnologia

de

objetos

distribuídos,

definida

pelo

OMG

(http://www.omg.org) que utiliza para comunicação o protocolo IIOP; • DCOM, tecnologia da Microsoft para objetos distribuídos; • JEE, tecnologia Java para objetos distribuídos baseada no protocolo RMIIIOP; • DDObjects, framework de objetos distribuídos utilizado pelo Delphi; • Pyro, framework de objetos distribuídos que utiliza Python; Objetos distribuídos Objetos distribuídos normalmente são utilizados em soluções corporativas, sendo instanciados em pools do lado servidor e acessados remotamente por clientes, os quais podem ser também outros servidores. Em termos gerais, objetos locais e distribuídos diferem em vários aspectos. -

Ciclo de vida: criação, migração e exclusão de objetos distribuídos são diferentes de objetos locais.

-

Referência: referências remotas a objetos distribuídos são mais complexas do que os ponteiros simples para endereços de memória.

-

Latência do pedido: uma solicitação de objetos distribuídos é mais lenta do que a invocação de métodos locais.

-

Ativação do objeto: objetos distribuídos podem não estar sempre disponíveis para servir uma solicitação de objeto em qualquer instante.

-

Paralelismo: é comum objetos distribuídos serem executados em paralelo.

ARQUITETURA ORIENTADA A SERVIÇOS - SOA E WEBSERVICES

68

-

Comunicação: há diferentes primitivas de comunicação disponíveis para solicitações de objetos distribuídos.

-

Falha: objetos distribuídos têm muito mais pontos de falha que objetos típicos locais.

-

Segurança: distribuição aumenta a vulnerabilidade a ataques, exigindo ferramentas próprias de autenticação e uso.

CORBA Criado pelo OMG (Object Management Group), o CORBA (Common Object Request Broker Architecture) trata de uma arquitetura padrão com o objetivo de estabelecer e simplificar a troca de dados entre sistemas distribuídos heterogêneos baseados em objetos. O grande diferencial do CORBA frente a outros sistemas de objetos distribuídos é a preocupação em garantir a interoperabilidade, pois as suas interfaces de exposição de serviços seguem uma sintaxe independente, e plataformas como Java e dotNet apresentam ferramentas próprias para gerar os stubs de forma automatizada, deixando a comunicação transparente ao programador, segundo o padrão Proxy.

ARQUITETURA ORIENTADA A SERVIÇOS - SOA E WEBSERVICES

69

Essa interface de exposição de serviços é 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 repositório, ou catálogo, de como os serviços devem ser utilizados pelas mais diversas linguagens. No vocabulário 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 comunicação especificamente, o qual utiliza IIOP (Internet Inter-ORB Protocol) como protocolo padrão.

Atenção Em termos práticos, o uso de ORB pelo CORBA define um midleware mais estratégico e mais sofisticado conceitualmente que

outros

midlewares,

como

RPC

e

MOM.

Entre

as

características de um ORB encontram-se: • Serviços de gerenciamento do ciclo de vida, incluindo criação, cópia, movimentação e deleção de alguns componentes;

ARQUITETURA ORIENTADA A SERVIÇOS - SOA E WEBSERVICES

70

• Serviço de persistência, incluindo a possibilidade de utilização de banco de dados; • Sistema de eventos, que permitem aos componentes especificarem quais eventos deverão ser notificados; • Controle de concorrência; • Serviços transacionais, permitindo desfazer alterações não confirmadas; • Serviço de nomes e diretórios para localização de componentes (COS Naming, ou Common Object Service Naming Services); • Opcionalmente um ORB pode apresentar também serviços de segurança e Time Stamp.

RMI-IIOP A principal arquitetura de objetos distribuídos comercial do Java é o JEE (Java Enterprise Edition) com seus componentes, denominados EJBs (Enterprise Java Beans), e essa arquitetura utiliza um protocolo de comunicação denominado RMI-IIOP. Mas qual o motivo para se utilizar uma camada IIOP, se a comunicação remota padrão para serviços distribuídos 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 serviços oferecidos pelo Java na plataforma JEE. O Java apresenta ferramentas para transformação direta do código-fonte das interfaces

ARQUITETURA ORIENTADA A SERVIÇOS - SOA E WEBSERVICES

71

RMI-IIOP em CORBA-IDL, facilitando ainda mais a disponibilização para outras plataformas. Inicialmente, deve ser criada a interface remota, da mesma forma que o RMI. Porém, para que a implementação esteja compatível com o CORBA, segundo o protocolo IIOP, deve ser utilizado um descendente de PortableRemoteObject.

A partir desta implementação 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 através do comando “rmic -iiop -idl exemplormi.CalcRemoteCORBA”, o que irá gerar um arquivo IDL com o conteúdo a seguir, permitindo a chamada do objeto remoto a partir de outras ferramentas, como Delphi e C++, segundo os princípios de interoperabilidade defendidos no contexto de arquiteturas orientadas a serviço.

/** * exemplormi/ICalcRemote.idl ARQUITETURA ORIENTADA A SERVIÇOS - SOA E WEBSERVICES

72

* 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

É através desse arquivo IDL, criado pelo rmic, que ferramentas de apoio a tecnologias, como Visual Studio dotNet, podem gerar os clientes CORBA de forma simplificada.

ARQUITETURA ORIENTADA A SERVIÇOS - SOA E WEBSERVICES

73

Java Enterprise Edition A arquitetura JEE é baseada em componentes denominados Enterprise Java Beans, os quais são instanciados em pools de objetos no servidor, disponibilizando através de fábricas 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 através do uso de RMI-IIOP para a camada de comunicação. Um Enteprise JavaBean (EJB) é um componente que pode ser implantado em um servidor de aplicações e utilizar seus serviços de forma declarativa ou não. 

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 aplicação) pode configurar os serviços que desejar e o código para chamá-los será gerado nos interceptadores durante a implantação;



Um EJB é um objeto distribuído, mas não é um objeto remoto. No entanto, seu interceptador pode ser um, caso utilize RMI-IIOP.

Atenção Embora as anotações incluídas na versão JEE5 tenham simplificado muito a construção de aplicativos corporativos com Java, na versão J2EE a arquitetura do framework ficava mais acessível ao programador, permitindo entender a filosofia básica

ARQUITETURA ORIENTADA A SERVIÇOS - SOA E WEBSERVICES

74

do JEE. Em termos gerais, os EJBs são instanciados em pools no servidor, sendo acionados através de interfaces locais ou remotas, criadas a partir de fábricas próprias.

A figura seguinte mostra o funcionamento da arquitetura JEE. Nenhum EJB pode ser acessado diretamente. Para os clientes remotos, estes devem acessar a fábrica 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 fábrica local (EJBLocalHome) para a criação de interfaces de acesso similares, mas que trabalham localmente, sendo derivadas de EJBLocalObject.

(figura representativa da arquitetura JEE)

O modelo de criação de interfaces, em ambos os casos, segue o padrão Abstract Factory, enquanto a comunicação de EJBObject segue o padrão Proxy com protocolo RMI-IIOP, e os pools de EJBs seguem o padrão Fly Weight. Além desses, vários outros padrões de desenvolvimento estão presentes no JEE. Como as fábricas são únicas para cada classe de EJB específica, elas são nomeadas e acessadas via JNDI, o que denota a presença de um padrão

ARQUITETURA ORIENTADA A SERVIÇOS - SOA E WEBSERVICES

75

Singleton implícito. Os padrões de desenvolvimento presentes na arquitetura J2EE podem ser observados na figura em questão.

Existem três tipos de EJBs: • SessionBean, para processos de negócios síncronos; • EntityBean, para persistência; • Message Driven Bean (MDB), para processos de negócios assíncronos; O único tipo de EJB que não segue o modelo de ativação descrito, com o uso de fábricas de interfaces, é o MDB, pois ele é ativado através do JMS, conforme visto em aulas anteriores desta disciplina. Quanto aos EntityBeans, foram substituídos pelo JPA (Java Persistence Architecture) no JEE5 devido a questões de performance. Finalmente, os SessionBeans podem ser divididos em dois tipos distintos: -

Stateless, os quais não guardam estado entre transações sucessivas;

-

Stateful, que ao contrário dos primeiros, guarda estado entre transações.

ARQUITETURA ORIENTADA A SERVIÇOS - SOA E WEBSERVICES

76

O código seguinte demonstra a criação de um EJB Stateless, segundo a sintaxe anotada do JEE5, bem como suas interfaces (local e remota). Observa-se que, com o uso de anotações, a codificação das fábricas 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 código abaixo:

ARQUITETURA ORIENTADA A SERVIÇOS - SOA E WEBSERVICES

77

Chamada de JEE por ferramentas CORBA É possível utilizar o J2EE (Java 2 Enterprise Edition) para gerar EJBs acessíveis a partir de outras plataformas com suporte a CORBA. Nessa versão do JEE os componentes não são anotados, sendo sua programação levemente mais trabalhosa que as versões a partir do JEE5. // Interface remota que utiliza o protocolo RMI-IIOP public interface Logger extends EJBObject { void logString(String message) throws RemoteException; } // Fábrica de interfaces remotas public interface LoggerHome extends EJBHome { Logger create() throws RemoteException, CreateException;} O exemplo aqui utilizado está disponível na documentação da Oracle, no endereço http://docs.oracle.com/javase/7/docs/technotes/guides/rmi-

ARQUITETURA ORIENTADA A SERVIÇOS - SOA E WEBSERVICES

78

iiop/interop.html. Inicialmente devem ser criados a interface remota do EJB e também a fábrica de interfaces remotas. Após a definição desses componentes, o EJB em si deve ser criado, nesse caso um SessionBean. Para efetuar o deploy deste EJB seria necessário ainda a configuração nos arquivos XML corretos. Com relação à interoperabilidade via IIOP, o passo seguinte seria a geração dos arquivos IDL através do programa rmic. Chamada de JEE por ferramentas CORBA Com relação à interoperabilidade via IIOP, o passo seguinte seria a geração dos arquivos IDL através do programa rmic, conforme o modelo abaixo: rmic -idl -noValueMethods –classpath $J2EE_HOME/lib/j2ee.jar: -d ejbinterop.Logger ejbinterop.LoggerHome Serão gerados os seguintes arquivos, lembrando que apenas dois são específicos para esse EJB (Logger.idl e LoggerHome.idl), sendo os demais apenas arquivos padrão de suporte à comunicação 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

ARQUITETURA ORIENTADA A SERVIÇOS - SOA E WEBSERVICES

79

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 código abaixo que foi gerado em C++ pelo ORBacus 4.0.5. Os comentários gerados foram suprimidos para evitar uma quantidade maior de linhas no exemplo. #include #include #include #include #include #include #include #include #include void run(CORBA::ORB_ptr orb, const char* logger_home_url) { cout _remove_ref(); factory = new javax::ejb::CreateException_init; orb -> register_value_factory(javax::ejb::CreateException::_OB_id(),factory); factory -> _remove_ref(); factory = new javax::ejb::RemoveException_init; orb -> register_value_factory(javax::ejb::RemoveException::_OB_id(), factory);

ARQUITETURA ORIENTADA A SERVIÇOS - SOA E WEBSERVICES

81

factory -> _remove_ref(); run(orb, argv[1]); } catch(const CORBA::Exception& ex) { cerr ]> Tove Jani Reminder Don't forget me this weekend

ARQUITETURA ORIENTADA A SERVIÇOS - SOA E WEBSERVICES

99

A seguir, um exemplo de XSD (XML Schema Datatype) apresentado pela W3C (http://www.w3schools.com/schema/):



Em termos gerais, devido à sua flexibilidade, o uso de XSD foi mais difundido, sendo utilizado em várias plataformas tecnológicas da atualidade, como nos webservices.

Linguagens de transformação Outra preocupação com relação aos dados presentes nos arquivos XML, além da definição de vocabulários adequados, é a possibilidade de transformar esses dados para algum outro formato de visualização ou exportação. Nesse ponto surgem as linguagens de transformação, como XSLT e XSL-FO, ambas seguindo a sintaxe XML para efetuar as transformações 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 informação deve ser apresentada de diferentes formas, em diferentes dispositivos, as linguagens de transformação acabam fornecendo uma ótima solução para

ARQUITETURA ORIENTADA A SERVIÇOS - SOA E WEBSERVICES

100

evitar o retrabalho na construção de múltiplas interfaces para o mesmo software.

XSLT O uso de XSLT é muito comum no controle da aparência visual de arquivos XML, quando disponibilizados em navegadores para web, como ocorre para os recursos de notícias RSS. Uma estrutura comum nos sites da atualidade é composta de linguagem de dados XML, linguagem de estruturação XHTML ou HTML 5, linguagem de transformação XSLT e linguagem de formatação CSS, além das ações da página providas por Java Script e JSON, muitas vezes ainda apoiado em bibliotecas como JQuery UI. Os dados XML são transformados via XSLT para uma visualização XHTML-CSS ou HTML5-CSS. Considere o arquivo XML a seguir:

Com a utilização de um arquivo XSL apropriado, como o apresentado a seguir, é possível controlar sua visualização no navegador.

XSLT Os comandos do XSLT normalmente utilizam o prefixo xsl, porém nada impediria de se utilizar outro prefixo. A tabela seguinte apresenta alguns dos comandos disponíveis na sintaxe do XSLT.

ARQUITETURA ORIENTADA A SERVIÇOS - SOA E WEBSERVICES

101

Comando

Utilização

Exemplo

Output

Define o formato de saída



template

Define o modelo a ser aplicado quando determinado tipo de nó for encontrado

applytemplate

Aplica um modelo ao elemento corrente ou nós filhos do mesmo



value-of

Retorna o valor do nó



Variable

Declara uma variável local

ElementDescription

copy-of

Copia o valor do nó

for-each

Repete para cada nó do conjunto selecionado



Sort

Ordena a saída para um conjunto for-each



If

Testa uma condição para o elemento corrente



choose, when e otherwise

Trabalham em conjunto, iniciado por choose, e definindo qual ação executar quando satisfeita a condição de when, e o que fazer quando nada for satisfeito através de otherwise







Preço normal Oferta!

Uma listagem completa dos comandos do XSLT está disponível no endereço .

ARQUITETURA ORIENTADA A SERVIÇOS - SOA E WEBSERVICES

102

XSL-FO Quanto ao XSL-FO (XML Stylesheet Language - Formatting Objects), este destina-se à criação de documentos em formatos voltados para plataformas específicas, como arquivos PDF, por exemplo.

A sintaxe XSL-FO apresenta um conjunto muito rico de opções para formatação, paginação e tipografia de documentos. O nó raiz da árvore de objetos de formatação deve ser um fo:root. Os filhos possíveis do fo:root são um único fo:layout-master-set, opcionalmente

ARQUITETURA ORIENTADA A SERVIÇOS - SOA E WEBSERVICES

103

fo:declarations e fo:bookmark-tree, e uma sequência de um ou mais elementos fo:page-sequence-wrapper e fo:page-sequence. Enquanto fo:layout-master-set define a geometria e sequenciamento das páginas; os filhos do fo:pagesequence, que são chamados de fluxos (contidos em fo:flow e fo:staticcontent), fornecem o conteúdo que é distribuído nas páginas. Os comandos anteriores fazem parte do aspecto de paginação e formatação do XSL-FO, sendo a árvore completa apresentada a seguir.

Também são utilizados vários atributos que permitem justificar o texto ou alterar a fonte e caracteres (internacionalização), como font-selection-strategy, font-weight e country. Também são utilizados vários atributos que permitem justificar o texto ou alterar a fonte e caracteres (internacionalização), como font-selection-strategy, font-weight e country. Um exemplo de arquivo de transformação XSL-FO é apresentado a seguir.



ARQUITETURA ORIENTADA A SERVIÇOS - SOA E WEBSERVICES

104

1. Primeiro Exemplo 2. Segundo Exemplo 3. Terceiro Exemplo

Normalmente, esse tipo de documento é gerado com o uso de XSLT, isso devido às informações dinâmicas providas via XML, como no pequeno trecho de código abaixo:

Através de um aplicativo como o FOP (Formatting Objects Processor), desenvolvido em Java e hoje conhecido como Apache FOP, é possível a conversão das fontes FO (Formatting Objects) em formatos diversos, entre eles: PDF, ASCII, PostScript, SVG e RTF.

ARQUITETURA ORIENTADA A SERVIÇOS - SOA E WEBSERVICES

105

Outras tecnologias XML Vários outros exemplos de uso de XML podem ser encontrados no mercado, incluindo tecnologias que foram absorvidas pelo HTML 5 na concepção de páginas segundo o foco da Web 2.0. Algumas dessas tecnologias são apresentadas a seguir: 

SVG (Scalable Vector Graphics), para a construção de gráficos vetoriais em XML;



XMI (XML Metadata Interchange), utilizado para troca de informações de metadados entre ferramentas de modelagem UML (Unified Modeling Language);



MathML, utilizado na representação de modelos matemáticos;



SOAP (Simple Object Access Protocol), protocolo de transmissão de dados utilizado por Web Service;



SMIL

(Synchronized

Multimedia

Integration

Language),

para

a

construção de apresentações multimídia interativas; 

CML (Chemical Markup Language), para a formulação de elementos químicos.

Atividade proposta Como atividade de fixação, crie uma página XSLT para apresentar o XML seguinte no formato visual desejado.

ARQUITETURA ORIENTADA A SERVIÇOS - SOA E WEBSERVICES

106

Referências 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

ARQUITETURA ORIENTADA A SERVIÇOS - SOA E WEBSERVICES

107

Exercícios de fixação Questão 1 "Elemento do XML que não é interpretado segundo as regras sintáticas do mesmo, se comportando como texto corrido." Esta é a definição de que componente da sintaxe XML? a) Nó de texto b) Seção CDATA c) Atributo d) Comentário e) Instrução de Processamento Questão 2 Uma forma de definir gramáticas XML com sintaxe bastante simples, porém sem uso de namespaces e sem a possibilidade de trabalhar com estruturas de dados complexas, seria através de: a) CSS b) XSD c) XSL d) DTD e) RPC Questão 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) Comentário c) Nó de Texto d) Atributo e) NameSpace

ARQUITETURA ORIENTADA A SERVIÇOS - SOA E WEBSERVICES

108

Questão 4 As entidades seguem a sintaxe &ENTIDADE; e podem representar caracteres especiais ou elementos da tabela ASCII. Qual das entidades abaixo não está corretamente descrita em termos do que representa? a) A significa "espaço" b) < significa "menor que" c) > significa "maior que" d) & significa "&" e) ' significa "apóstrofe" Questão 5 Uma forma de definir gramáticas XML com uso da própria sintaxe XML e namespaces, e com a possibilidade de trabalhar com estruturas de dados complexas, seria através de: a) CSS b) XSD c) XSL d) DTD e) RPC Questão 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 Questão 7 Qual o nome da tecnologia utilizada para a construção de gráficos vetoriais em XML?

ARQUITETURA ORIENTADA A SERVIÇOS - SOA E WEBSERVICES

109

a) MathML b) CML c) XMI d) SMIL e) SVG Questão 8 Tecnologia preparada para a geração de arquivos binários, destinada à criação de documentos em formatos voltados para plataformas específicas, como PDF: a) XSLT b) CML c) XSL-FO d) MathML e) SVG Questão 9 Para que serve o comando template no XSL? a) Define o formato da saída. 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 variável. Questão 10 Os elementos que efetivamente fornecem o conteúdo a ser distribuídos nas páginas, 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

ARQUITETURA ORIENTADA A SERVIÇOS - SOA E WEBSERVICES

110

Aula 5 Exercícios de fixação Questão 1 - B Justificativa: Apenas a seção 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 inclusão de código-fonte em alguma linguagem dentro de um arquivo XML. Questão 2 - D Justificativa: São duas as formas de definir gramáticas: DTD e XSD. Quanto ao texto, este se refere ao DTD, pois o mesmo apresenta como características: – Sintaxe bastante simples, mas não no padrão do XML. – Não permite o uso de namespaces. – Não permite a definição de estruturas de dados complexas. Questão 3 - E Justificativa: Devem ser utilizados namespaces sempre que duas ou mais gramáticas se cruzam dentro do mesmo arquivo XML. Entidades são utilizadas para caracteres especiais, e os demais são componentes estruturais comuns de qualquer XML. Questão 4 - A Justificativa: O código ASCII 65, assinalado pela entidade A corresponde ao caractere "A" (letra a maiúscula). Os demais estão corretos. Questão 5 - B Justificativa: São duas as formas de definir gramáticas: DTD e XSD. Quanto ao texto, este se refere ao XSD, pois o mesmo apresenta como características: – Sintaxe mais complexa, dentro das regras do XML. – Permite a utilização de namespaces.

ARQUITETURA ORIENTADA A SERVIÇOS - SOA E WEBSERVICES

111

– Permite a definição de estruturas de dados complexas. Questão 6 - A Justificativa: O comando que causa uma repetição para cada elemento do conjunto é o for-each. Com relação ao select, este determina o que será selecionado para o conjunto, enquanto os demais elementos (if, choose e when) servem para desvios condicionais. Questão 7 - E Justificativa: SVG (Scalable Vector Graphics) é utilizado para a construção de gráficos vetoriais em XML, sendo amplamente utilizado no HTML 5. Quanto aos demais: - XMI (XML Metadata Interchange), utilizado para troca de informações de metadados

entre

ferramentas

de

modelagem

UML

(Unified

Modeling

Language). - MathML, utilizado na representação de modelos matemáticos. - SMIL (Synchronized Multimedia Integration Language), para a construção de apresentações multimídia interativas. - CML (Chemical Markup Language), para a formulação de elementos químicos. Questão 8 - C Justificativa: A tecnologia XSL-FO (XML Stylesheet Language - Formatting Objects), este destina-se à criação de documentos em formatos voltados para plataformas específicas, como arquivos PDF, por exemplo. Diferencia-se do XSLT padrão, pois este último faz transformações em modo texto. Quanto ao SVG, o MathML e o CML, estas são tecnologias XML para domínios específicos, sendo respectivamente: gráficos, matemática e química. Questão 9 - B Justificativa: Para definir o formato de saída é utilizado o comando output; value-of retorna o valor do nó selecionado; variable declara uma variável local; apply-template aplica um modelo ao elemento corrente e filhos do mesmo.

ARQUITETURA ORIENTADA A SERVIÇOS - SOA E WEBSERVICES

112

Quando utilizamos template estamos definindo o modelo que será aplicado (com apply-template) a determinado tipo de nó for encontrado em um conjunto selecionado. Questão 10 - E Justificativa: O nó raiz da árvore de objetos de formatação deve ser um fo:root. Os filhos possíveis do fo:root são um único fo:layout-master-set, opcionalmente fo:declarations e fo:bookmark-tree, e uma seqüência de um ou mais elementos fo:page-sequence-wrapper e fo:page-sequence. Enquanto fo:layout-master-set define a geometria e sequenciamento das páginas; os filhos do fo:pagesequence, que são chamados de fluxos (contidos em fo:flow e fo:staticcontent), fornecem o conteúdo que é distribuído nas páginas.

ARQUITETURA ORIENTADA A SERVIÇOS - SOA E WEBSERVICES

113

Introdução Com a popularização da Internet e aumento do comércio eletrônico, torna-se comum a necessidade de integração entre sistemas de diferentes plataformas, muitas vezes visando às transações financeiras e à logística. Nesse novo cenário, o uso de XML em plataformas de serviços estilo RPC, inicialmente utilizando soluções XML-RPC e posteriormente Web Services, apresenta-se como uma grande solução de integração, garantindo a interoperabilidade com acoplamento extremamente baixo. Com esse tipo de solução, novos horizontes se abriram, e sistemas voltados para o comércio entre empresas passaram a definir o conceito de B2B, posteriormente sendo expandido para o comércio direto com o consumidor, denominado B2C. Objetivo: 1. Compreender o XML-RPC e o SOAP; 2. Implementar a interoperabilidade via Web Services.

ARQUITETURA ORIENTADA A SERVIÇOS - SOA E WEBSERVICES

114

Conteúdo XML-RPC Uma solução simples para a criação de aplicativos distribuídos interoperáveis é o uso de XML-RPC, opção de arquitetura na qual as chamadas e respostas RPC seguem o formato XML para os dados de envio e recepção. Características do XML-RPC: 

Criado para ser tão simples quanto possível, definindo as interfaces de chamadas remotas, mas não implementando os métodos ouvintes nos servidores;



Utiliza um vocabulário baseado em XML;



Tem uma quantidade limitada de comandos (tags) para descrever funções, tipos de parâmetros e tipos de retorno;



Utiliza o protocolo HTTP para o transporte na Internet;



Voltado para a comunicação computador a computador, e não de usuário a computador;



O uso do protocolo HTTP e sintaxe XML permite sua passagem livre por firewalls;



Várias implementações 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)

ARQUITETURA ORIENTADA A SERVIÇOS - SOA E WEBSERVICES

115

Entre os elementos da sintaxe XML-RPC encontram-se: 

methodCall: Chamada de um método remoto a partir do cliente.



mehodResponse: Define a resposta enviada pelo servidor ao cliente.



methodName: Nome do método chamado no servidor.



Params: Setor de parâmetros da chamada ou resposta.



Param: Define um parâmetro, devendo conter seu valor e tipo.

Os tipos aceitos no XML-RPC podem ser observados na seguinte tabela:

Além desses tipos, podem ser criadas estruturas mais complexas com o uso de struct, como no exemplo a seguir:

ARQUITETURA ORIENTADA A SERVIÇOS - SOA E WEBSERVICES

116

Cada elemento de struct deve conter nome e valor, onde o valor pode ser outro struct, aplicado de forma recursiva. Também podem ser criadas coleções com o uso de array, podendo ter como elementos dessas coleções elementos struct, os quais podem também utilizar array nos seus valores (value). Logo, a combinação de estruturas complexas e coleções (ou vetores), de forma dinâmica e recursiva, permite expressar tipos de dados diversos com grande facilidade, o que viabiliza a implementação de clientes e servidores nas mais diversas plataformas. É importante observar também 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 código do erro (faultCode) e mensagem do erro (faultString).

ARQUITETURA ORIENTADA A SERVIÇOS - SOA E WEBSERVICES

117

Implementação em Java Em termos de Java, uma biblioteca muito interessante para trabalhar com XMLRPC é disponibilizada pelo Apache, sendo seu uso baseado no mapeamento de um simples Servlet, um arquivo de propriedades e uma classe de negócios bem independente.

ARQUITETURA ORIENTADA A SERVIÇOS - SOA E WEBSERVICES

118

Com esses poucos componentes é criada a parte servidora do XML-RPC, sendo o cliente tão simples quanto, como pode ser observado a seguir.

SOAP Em termos gerais, o SOAP (Simple Object Access Protocol) define um protocolo de comunicação remota estilo RPC com uso de XML, extensível e amplamente utilizado na comunicação com Web Services. Suas características principais são: 1: Objetivar a comunicação entre aplicativos; 2: Definir um formato padrão para envio de mensagens; 3: Permitir a comunicação na Internet de forma transparente aos firewalls; 4: Ser independente de plataforma e de linguagem de programação; 5: Utilizar sintaxe XML, bastante simples e extensível; 6: É uma recomendação 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; ARQUITETURA ORIENTADA A SERVIÇOS - SOA E WEBSERVICES

119

• Não pode ser utilizado um DTD; • Não são permitidas instruções de processamento XML. O esqueleto de uma mensagem SOAP é apresentado a seguir: A seção Header é opcional e permite a inclusão de informações específicas do aplicativo, como autenticação e pagamento, por exemplo. Se essa seção estiver presente deverá constar como o primeiro elemento filho do envelope SOAP. A seção Header é opcional e permite a inclusão de informações específicas do aplicativo, como autenticação e pagamento, por exemplo. Se essa seção 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 serviço solicitado. Os elementos filhos de Body devem ter o namespace qualificado, como no exemplo seguinte com a chamada e a resposta.

IBM



ARQUITETURA ORIENTADA A SERVIÇOS - SOA E WEBSERVICES

120

34.5

A seção 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 ocorrência nessa mensagem. Os subelementos de Fault são apresentados na tabela a seguir. Subelemento

Significado



Código do erro ocorrido



Mensagem do erro



Informações acerca do responsável pela falha



Engloba informações específicas do aplicativo referentes ao erro.

ARQUITETURA ORIENTADA A SERVIÇOS - SOA E WEBSERVICES

121

Web Services O conceito de serviços não é novidade em termos de programação, tratando de componentes independentes de software que podem ser acionados para realizar determinadas tarefas, permitindo através de seu conjunto realizar ações maiores segundo uma ordem de chamada definida pelo aplicativo solicitante. Em termos de Internet, os tipos de serviço mais difundidos são 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 diferença funcional entre o SOAP e o REST é a de que, enquanto o SOAP foca as chamadas de métodos remotos, o REST trabalha com envio e recepção de objetos ou recursos. Várias bibliotecas, como JQuery, apresentam maior facilidade em lidar com REST, já que uma característica deste é justamente a simplicidade da transferência de informações, 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 utilização facilitada em grandes ferramentas corporativas.

SOAP Web Services Além do protocolo SOAP, utilizado na comunicação entre aplicativos para Web Services desse tipo, será necessário também um descritor de serviços, o WSDL (Web Service Description Language).

ARQUITETURA ORIENTADA A SERVIÇOS - SOA E WEBSERVICES

122

É através desse WSDL que diversas IDEs, como Visual Studio e NetBeans, conseguem criar o cliente com as chamadas corretas, deixando o programador com a sensação de que está fazendo uma simples chamada local, e sem envolver nenhum esforço para o mesmo na criação dos stubs de comunicação. Um documento WSDL define os serviços como coleções de endpoints ou portas. Em WSDL, a definição abstrata de endpoints e mensagens é independente de sua implantação na rede ou das conversões do formato de dados. Isso permite a reutilização de definições abstratas: mensagens, que são descrições abstratas dos dados que estão sendo trocados, e os tipos de portas, que são coleções abstratas de operações. As especificações do protocolo e formato de dados concretos para um tipo de porta em particular constitui um vinculativo reutilizável. Uma porta é definida através da associação de um endereço de rede com um vínculo reutilizável, e um conjunto de portas de definir um serviço. Feitas essas considerações, um documento WSDL usa os seguintes elementos na definição de serviços de rede: 

Types - Um recipiente para definições de tipo de dados usando algum tipo de gramática (como XSD).



Message - Uma definição abstrata do formato de dados da comunicação.



Operation - Uma descrição abstrata de uma ação suportada pelo serviço.



PortType - Um conjunto abstrato de operações apoiadas por um ou mais endpoints.



Binding - Um protocolo concreto e especificação do formato de dados para um tipo de porta (PortType) particular.



Port - Um endpoint simples, definido como uma combinação de um binding e um endereço de rede.



Service - Uma coleção de endpoints relacionados.

ARQUITETURA ORIENTADA A SERVIÇOS - SOA E WEBSERVICES

123

UDDI Opcionalmente, esses Web Services podem ser cadastrados em um sistema para catalogação de serviços denominado UDDI (Universal Discovery and Description Integration), o qual equivale, na prática, a um serviço de nomes e diretórios. A principal função do UDDI é retornar a URL do WSDL de um determinado serviço, após uma busca feita nos próprios registros desse catálogo, tendo como perfis de pesquisa: • White Pages, referindo-se à busca de serviços pelo nome; • Yellow Pages, tratando da busca por assunto; • Green Pages, baseado em características ténicas. Finalmente, é feita uma comparação no quadro seguinte entre as diversas tecnologias de processamento distribuídas comumente utilizadas no mercado em termos de protocolo, descritor de chamadas e serviço de nomes e diretórios.

Para os Web Services do tipo RESTful é utilizado um descritor de serviços denominado WADL (Web Application Description Language). Em termos gerais, os RESTful Web Services não mantinham uma preocupação com relação ao registro, como o uso de UDDI para SOAP Web Services; no entanto, as versões atuais do UDDI já incorporam elementos de busca para serviços REST, e o jUDDI permite que os registros sejam adicionados com sintaxe JSON.

ARQUITETURA ORIENTADA A SERVIÇOS - SOA E WEBSERVICES

124

A interoperabilidade através de Web Services é garantida pelo uso de protocolos modo texto de larga aceitação, como SOAP, e a presença de descritores de serviço WSDL para facilitar a criação dos stubs, permitindo a plena integração entre diferentes tecnologias e alto nível de reuso dos serviços e acoplamento extremamente baixo.

Criação de SOAP Web Services em Java A plataforma JEE5 trouxe grandes facilitadores, inclusive para a escrita de Web Services, pois ao contrário de diversos arquivos de configuração XML, hoje trabalhamos com simples código anotado.

As anotações utilizadas são: @WebService – define a classe como um serviço na Web; @WebMethod – define um método para esse serviço; @WebParam – utilizado para definir parâmetros de chamada de um determinado método do Web Service. Baseado nessas anotações, o servidor (GlassFish, por exemplo) implementa toda a infraestrutura para disponibilização do serviço, além de gerar a WSDL do mesmo, bem como o XSD (XML Schema), se fazer necessário.

ARQUITETURA ORIENTADA A SERVIÇOS - SOA E WEBSERVICES

125

Criação 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 opção que deve ser utilizada na criação do código necessário para a comunicação de forma automatizada. Após adicionar a referência ao serviço, este pode ser invocado de forma muito simples a partir do código na linguagem escolhida dentro da plataforma dotNet, como pode ser observado a seguir, com uso da linguagem C#.

ARQUITETURA ORIENTADA A SERVIÇOS - SOA E WEBSERVICES

126

É fácil 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 serviço garante a interoperabilidade.

Sistemas B2B e B2C Atualmente, os termos B2B e B2C são amplamente utilizados no mercado, mas o que realmente representam? B2B (Business to Business) é a sigla utilizada no comércio eletrônico para definir transações comerciais entre empresas. Em outras palavras, é um ambiente onde uma empresa comercializa seus produtos para outras empresas. A natureza dessa operação pode ser revenda, transformação ou consumo. B2C (Business to Consumer) é a sigla que define a transação comercial entre empresa e consumidor final através de uma plataforma de e-commerce. A natureza dessa operação tende a ser apenas de consumo. Os Web Services representam um passo à frente para permitir a colaboração entre várias entidades na Web e na superação dos problemas de interoperabilidade que podem aparecer. Parceiros B2B podem se beneficiar ao permitir que as entidades de negócios exponham suas interfaces de modo simples e interoperável. Sistemas de informação baseados em uma arquitetura orientada a serviços que são capazes de integrar diferentes funcionalidades e oferecer um modelo de componente virtual que abstrai da peculiaridade de implementações específicas parecem ser uma solução muito atraente. O ambiente de execução de Web Services apoia B2B comum e cenários B2C, na qualidade de um sistema de informação que representa o ponto central de uma arquitetura de hub-and-spoke. Se dois parceiros desejam se comunicar, eles

ARQUITETURA ORIENTADA A SERVIÇOS - SOA E WEBSERVICES

127

simplesmente

resumem

suas

funcionalidades

via

Web

Services,

não

diretamente um para o outro. É feita uma distinção clara entre a interface e a implementação de um serviço, o que permite o registro, descoberta, composição e execução sem o conhecimento da localização da sua aplicação e tecnologia de implementação. Além disso, essa distinção apoia a definição semântica de um serviço, mesmo quando a sua aplicação não é necessariamente baseada em tecnologia semântica, mas talvez em um sistema legado. Em ambientes onde existe a necessidade de comunicação assíncrona entre empresas, como no modelo bancário, é também 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 operações matemáticas básicas: soma, subtração, multiplicação e divisão. Utilize a opção "Testar Web Service” disponível a partir do NetBeans com o uso deste servidor específico, e teste as funcionalidades do serviço criado.

ARQUITETURA ORIENTADA A SERVIÇOS - SOA E WEBSERVICES

128

Referências Laurent, S. Johnston, J. Dumbill, E. Programming Web Services with XMLRPC. Editora O’Reilly, 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 O’Reilly, 2007. Englander, R. Java and SOAP. Editora O’Reilly, 2002. Saudate, A. SOA aplicado: Integrando com web services e além. Editora Casa do Código, 2012.

ARQUITETURA ORIENTADA A SERVIÇOS - SOA E WEBSERVICES

129

Exercícios de fixação Questão 1 Qual das opções abaixo NÃO é uma característica do XML-RPC? a) Criado para ser tão simples quanto possível, definindo as interfaces de chamadas remotas, mas não implementando os métodos ouvintes nos servidores. b) Utiliza um vocabulário baseado em JSON. c) Tem uma quantidade limitada de comandos (tags) para descrever funções, tipos de parâmetros e tipos de retorno. d) Utiliza o HTTP para o transporte na Internet. e) Voltado para a comunicação computador a computador, e não de usuário a computador. Questão 2 Em termos de XML-RPC, quando ocorre um erro no atendimento à solicitação, a mensagem referente a este erro será retornada em que elemento da resposta? a) params b) faultCode c) faultString d) param e) methodName Questão 3 Com relação à sintaxe do SOAP, qual das opções 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) Não são permitidas instruções de processamento XML.

ARQUITETURA ORIENTADA A SERVIÇOS - SOA E WEBSERVICES

130

Questão 4 "Para o SOAP a seção _________ é opcional, e permite a inclusão de informações específicas do aplicativo, como autenticação e pagamento, por exemplo. Se esta seção estiver presente deverá constar como o primeiro elemento filho do envelope." Qual opção preenche corretamente a lacuna? a) Body b) Footer c) Fault d) Header e) Tail Questão 5 Considere as afirmativas abaixo, com relação ao SOAP: I - Objetiva a comunicação entre o servidor e o usuário final. II – Permite a comunicação na Internet de forma transparente aos firewalls. III – Utiliza sintaxe JSON. IV – É independente de plataforma e de linguagem de programação. Qual a opção que indica a quantidade de afirmativas corretas? a) As quatro estão corretas. b) Apenas três estão corretas. c) Apenas duas estão corretas. d) Apenas uma está correta. e) Nenhuma das afirmativas está correta. Questão 6 Para Web Services SOAP é utilizado um descritor de serviços denominado: a) WSDL b) UDDI c) XML d) SOAP e) REST

ARQUITETURA ORIENTADA A SERVIÇOS - SOA E WEBSERVICES

131

Questão 7 Para definir um Web Service em linguagem Java através de anotações, a classe deve ser anotada com _________, cada método que precise ser exposto como serviço deve ser anotado com __________, e cada parâmetro presente em cada um desses métodos deve ser anotado com _________. Qual opção 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 Questão 8 Um componente de grande relevância nos ambientes de computação distribuída é o sistema de registro, normalmente um serviço de nomes e diretórios. Quais são, 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. Questão 9 Considerando-se os documentos WSDL, qual elemento é relacionado a "um conjunto abstrato de operações apoiados por um ou mais endpoints"? a) Message b) Types c) Binding d) PortType e) Service

ARQUITETURA ORIENTADA A SERVIÇOS - SOA E WEBSERVICES

132

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

ARQUITETURA ORIENTADA A SERVIÇOS - SOA E WEBSERVICES

133

Aula 6 Exercícios de fixação Questão 1 - B Justificativa: A tecnologia XML-RPC utiliza um vocabulário baseado em XML. As demais opções estão corretas. Questão 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 código do erro (faultCode) e mensagem do erro (faultString). Questão 3 - D Justificativa: A sintaxe do SOAP não permite o uso de DTD. As demais opções estão corretas. Questão 4 - D Justificativa: A opção Header preenche corretamente a lacuna. A seção Body está relacionada à chamada e resposta do serviço, e a seção Fault refere-se à ocorrência de um erro qualquer. Quanto a Footer e Tail, estas opções não existem no SOAP. Questão 5 - C Justificativa: As afirmativas II e IV estão corretas, no entanto a I está incorreta, pois o foco do SOAP é a comunicação entre aplicativos, e a III está incorreta pelo fato de ser utilizado XML, e não JSON. Questão 6 - A Justificativa: Além do protocolo SOAP, utilizado na comunicação entre aplicativos para Web Services deste tipo, será necessário também um descritor

ARQUITETURA ORIENTADA A SERVIÇOS - SOA E WEBSERVICES

134

de serviços, o WSDL (Web Service Description Language). É através deste WSDL que diversas IDEs, como Visual Studio e NetBeans, conseguem criar o cliente com as chamadas corretas, deixando o programador com a sensação de que está fazendo uma simples chamada local, e sem envolver nenhum esforço para o mesmo na criação dos stubs de comunicação. Questão 7 - E Justificativa: As anotações utilizadas para definir o Web Service são: @WebService – define a classe como um serviço na Web. @WebMethod – define um método para este serviço. @WebParam – utilizado para definir parâmetros de chamada de um determinado método do Web Service. Questão 8 - B Justificativa: O quadro seguinte mostra uma síntese das diversas plataformas e componentes.

Segundo o quadro, o RMI-IIOP utiliza JNDI, CORBA utiliza COS Naming e os Web Services trabalham com UDDI. Questão 9 - D Justificativa: Um documento WSDL usa os seguintes elementos na definição de serviços de rede: - Types - Um recipiente para definições de tipo de dados usando algum tipo de gramática (como XSD). - Message - Uma definição abstrata do formato de dados da comunicação. - Operation - Uma descrição abstrata de uma ação suportada pelo serviço.

ARQUITETURA ORIENTADA A SERVIÇOS - SOA E WEBSERVICES

135

- PortType - Um conjunto abstrato de operações apoiadas por um ou mais endpoints. - Binding - Um protocolo concreto e especificação do formato de dados para um tipo de porta (PortType) particular. - Port - Um endpoint simples, definido como uma combinação de um binding e um endereço de rede. - Service - uma coleção de endpoints relacionados. Questão 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 métodos remotos, o REST trabalha com envio e recepção de objetos ou recursos. Quanto às demais opções, WADL descreve um Web Service REST, enquanto WSDL descreve um do tipo SOAP, e UDDI é o serviço de registro e localização de Web Services.

ARQUITETURA ORIENTADA A SERVIÇOS - SOA E WEBSERVICES

136

Introdução Como solução para a gestão de ambientes heterogêneos e reuso de componentes já existentes, surge uma nova filosofia em termos arquiteturais para a criação de sistemas corporativos. As arquiteturas orientadas a serviços tratam as diferentes tecnologias envolvidas, sejam elas novas ou antigas, a exemplo dos mainframes, como simples componentes que deverão expor ou consumir serviços, sempre intermediados pelo ferramental provido na arquitetura. Objetivo: 1. Compreender os princípios fundamentais de uma arquitetura orientada a serviços; 2. Analisar as possibilidades de integração entre plataformas e uso de tecnologias legadas.

ARQUITETURA ORIENTADA A SERVIÇOS - SOA E WEBSERVICES

137

Conteúdo Princípios do SOA O que é? As arquiteturas orientadas a serviços (SOA, do inglês Service Oriented Architecture) são a evolução natural da concepção de sistemas, visando o reuso e a interoperabilidade. Como funciona? Um serviço é definido como uma função independente, sem estado (stateless), que aceita uma ou mais requisições e devolve uma ou mais respostas por meio de uma interface padronizada e bem-definida. E também Serviços podem também realizar partes discretas de um processo, tal como editar ou processar uma transação, e não devem depender do estado de outras funções ou processos. A tecnologia utilizada para prover o serviço, tal como uma linguagem de programação não pode fazer parte da definição do mesmo. Incialmente os sistemas eram monolíticos, passando a trabalhar com metodologias estruturadas ou orientadas a objetos. Com o uso de redes, passamos a ter sistemas cliente-servidor, os quais evoluíram para sistemas divididos em camadas, como na arquitetura MVC (Model, View e Control). Com as necessidades transacionais e de distribuição de processamento, torna-se comum o uso de objetos distribuídos e posteriormente sistemas baseados em componentes corporativos. Finalmente surgem os serviços orientados a componentes, definindo a base do SOA. Uma

arquitetura

baseada

em

componentes

considera

a

divisão

das

funcionalidades do todo em funções menores, encapsuladas em componentes,

ARQUITETURA ORIENTADA A SERVIÇOS - SOA E WEBSERVICES

138

os quais podem estar em diferentes locais físicos, quando tratamos de objetos distribuídos. A grande vantagem dos componentes é o fácil reuso e sua substituição, o que simplifica a manutenção, caracterizando os requisitos de negócio principais no uso de SOA. Embora os Web Services sejam muitas vezes confundidos com o SOA em si, este é apenas o meio de interfaceamento de serviços mais comumente adotado nessa arquitetura. Outros elementos, como o ESB (Enterprise Service Bus) e ferramentas de orquestração de serviços devem estar presentes para viabilizar esse tipo de arquitetura. Um termo muito utilizado em termos de programação é "acoplamento ", que trata do nível de interdependência entre os módulos de um sistema. Uma das características do SOA é justamente o baixo acoplamento, e o módulo é considerado coeso quando possui uma atividade bem-definida e um baixo acoplamento. Um ambiente SOA deve ser independente de plataforma, conferindo a característica de neutralidade, e precisa ser baseado em padrões e apresentar contratos de uso formais entre os pontos de uso, o que determina obrigações específicas entre produtor e consumidor. Também deve ocorrer um grande nível de abstração do serviço frente a sua implementação, e apresentar meios de publicação popularizados, apresentando sempre a especificação das funcionalidades da interface do serviço, sem demonstrar sua implementação. Da mesma forma, um serviço deve ser consumível de forma prática, com ferramentas para descoberta e uso automatizado.

ARQUITETURA ORIENTADA A SERVIÇOS - SOA E WEBSERVICES

139

Qualquer funcionalidade do ambiente deve ser relevante, apresentando funções em uma granularidade reconhecida como significativa, bem como deve garantir o reuso do serviço sem a necessidade de cópia ou adaptações. Pode-se considerar o SOA como um paradigma arquitetural no qual componentes de aplicações são distribuídos, combinados e consumidos através de interfaces de serviços. Logo, não trata de uma tecnologia específica, e sim de uma metodologia de projeto e organização da infraestrutura de funcionalidades em um ambiente corporativo.

Conceitos de arquitetura orientada a serviço Alguns conceitos devem ser necessariamente implementados para viabilizar uma arquitetura orientada a serviços: Serviços Trata de funções disponibilizadas por um sistema computacional para outros sistemas. Deve funcionar de forma independente de outros serviços e possuir interface bem-definida, como no caso dos Web Services. Descritores Refere-se ao conjunto de parâmetros, regras e políticas envolvidas na chamada do serviço, tendo como exemplo o WSDL. Publicação e Descoberta A publicação de um serviço trata de sua divulgação, enquanto a descoberta ocorre quando um futuro consumidor desse serviço obtém informações acerca da existência do mesmo. Podem ser utilizados repositórios de registros ou serviços de nomes e diretórios. Exemplos de repositórios são o OASIS ebXML e UDDI, tratando de ferramentais onde podem ser armazenados e gerenciados artefatos como XML Schemas e WSDL.

ARQUITETURA ORIENTADA A SERVIÇOS - SOA E WEBSERVICES

140

Um serviço de nomes e diretórios provê informações acerca das ligações com determinados componentes. Nele são encontradas informações acerca da localização de descritores e objetos, como no caso do JNDI. Modelo de Dados Trata da especificação de um modelo de dados associado, como W3Cs WSDL, trazendo um vocabulário comum ao ambiente, o que permite a serialização de parâmetros em plataformas distintas, garantindo a interoperabilidade. Contratos de Serviço Os serviços devem ser utilizados segundo contratos bem-definidos, os quais devem ser aceitos pelo seu consumidor.

O que podemos observar é que a arquitetura orientada a serviços nada mais é que a evolução natural da arquitetura de sistemas tradicional para solucionar as necessidades de desenvolvimento e capacidade de adaptação às novas demandas, dentro de um mercado cada vez mais exigente em termos de qualidade e agilidade.

Governança e Segurança Outra característica desejável em arquiteturas desse tipo é a possibilidade de governança. Esse termo refere-se à gestão de políticas e processos necessários à boa utilização da arquitetura, com a definição de papéis e determinação de objetivos claros.

ARQUITETURA ORIENTADA A SERVIÇOS - SOA E WEBSERVICES

141

Com relação aos papéis, estes se referem às diversas pessoas envolvidas com o sistema, particularmente aquelas que assumem tarefas da gestão de tecnologia da informação e projetos. As políticas definem regras claras, que deverão ser seguidas por pessoas com diferentes papéis, para que os objetivos primordiais do uso da arquitetura sejam alcançados. 

Os processos definidos para garantir a governança do SOA envolvem:



Definição de políticas de uso da arquitetura;



Estabelecimento de metodologias de comunicação;



Estratégias de treinamento adequadas;



Implantação e acompanhamento de serviços.

Muitas empresas definem os serviços de forma avulsa, integrando-os sem trabalhar com princípios de governança, o que pode se tornar bastante complicado à medida que os projetos surgem e a necessidade de controle fica mais clara. Uma boa solução de governança deve compreender o gerenciamento de todo o ciclo de vida dos diversos ativos, sejam estes serviços, modelos, servidores, ou outros, e deverá, portanto, englobar todos os passos da criação até a remoção de um serviço, incluindo análise, modelagem, codificação, testes e implantação.

Telas sobre governança As figuras seguintes mostram duas telas voltadas para governança oferecidas por uma das ferramentas Oracle voltadas para o tema: Oracle Enterprise Manager SOA Management Pack Enterprise Edition. É possível observar, na primeira, o acesso a dados históricos em um painel de instrumentos com análises estatísticas, enquanto a segunda demonstra a gestão de transações de negócios através da ferramenta.

ARQUITETURA ORIENTADA A SERVIÇOS - SOA E WEBSERVICES

142

Aspectos de segurança Finalmente, os aspectos de segurança não podem ser deixados de lado em uma arquitetura orientada a serviços, e não basta pensar apenas em padrões de segurança para Web Services, como WS-Trust, WS-Security e SAML, mas sim ARQUITETURA ORIENTADA A SERVIÇOS - SOA E WEBSERVICES

143

tratar de políticas de segurança que envolvam todos os componentes da arquitetura. Entre os elementos de segurança, podemos citar a autenticação e autorização, referentes à identificação de um elemento (usuário, processo, componente, entre outros) e a permissão do acesso a recursos por parte do mesmo. Quanto às informações, é comum o uso de assinatura digital para garantir a autenticidade e a confidencialidade. Essas informações devem ser protegidas no trânsito (transporte) entre o serviço e seu consumidor, sendo comum o uso de protocolos como SSL (Secure Socket Layer) e TLS (Transport Layer Security). É necessária uma gestão da base de dados de usuários, bem como implementação de Políticas de Segurança, as quais denotam um conjunto de regras de negócio que estabelecem o comportamento de um sistema de computação, podendo envolver os mais diversos participantes. Outro elemento importante é a rastreabilidade, ou seja, a possibilidade de efetuar o acompanhamento dos eventos históricos de determinado usuário, de modo a apurar a responsabilidade sobre qualquer tipo de ação na utilização da arquitetura. Todo esse conjunto de aspectos de segurança acabam levando à necessidade de sistemas gestores bastante complexos. Como exemplo, a figura seguinte mostra a gestão de segurança do Oracle Fusion Middleware, o qual utiliza muitas ferramentas do Java como o Java Key Store e o JAAS (Java Authentication and Authorization Service).

ARQUITETURA ORIENTADA A SERVIÇOS - SOA E WEBSERVICES

144

Integração e uso de tecnologias legadas Sistema legado é o termo utilizado em referência aos sistemas computacionais de uma organização que, apesar de serem bastante antigos, fornecem serviços essenciais, sendo comum a utilização de bancos de dados obsoletos. Normalmente, são aplicações complexas, de difícil manutenção, e que pelo grau de criticidade e custo para modernização continuam ativas. Devido à falta de documentação e saída dos desenvolvedores inicialmente envolvidos nos projetos, os sistemas legados podem apresentar problemas como: • Dificuldade para a compreensão das regras de negócio originalmente implementadas; • Desconhecimento dos requisitos que levaram a tomar determinadas decisões; • Incoerência na estruturação dos módulos de código; • Miscelânea de estilos de programação;

ARQUITETURA ORIENTADA A SERVIÇOS - SOA E WEBSERVICES

145

• Obsolescência das ferramentas de desenvolvimento e bases de dados; • Indisponibilidade de mão de obra qualificada; • Impossibilidade de reaproveitamento dos equipamentos nos quais são executados; para execução de softwares mais atuais. Todos esses fatores encarecem a manutenção, e como a substituição do sistema pode ser inviável, o comum é que as empresas procedam à modernização do sistema, segundo duas metodologias específicas: Modernização do tipo “caixa branca” Modernização do tipo “caixa branca”, a qual é iniciada com um processo de engenharia reversa, no qual componentes do sistema e seus relacionamentos são identificados, gerando uma abstração de alto nível. Este tipo de modernização acaba levando à necessidade de compreensão dos códigos do sistema e acaba incluindo alguma reestruturação do mesmo. Modernização do tipo “caixa preta” Modernização do tipo “caixa preta”, a qual envolve apenas a análise de entradas e saídas do sistema legado dentro de um contexto operacional, de forma a identificar as interfaces desse sistema. Esse tipo de modernização envolve apenas o empacotamento do sistema com uma camada de software que esconde a complexidade do sistema original, ao mesmo tempo em que fornece uma interface moderna de comunicação com os atuais padrões do mercado.

Uso de SOA O uso de SOA estimula a reutilização dos aplicativos, os quais poderão durar décadas. Ou seja, os sistemas implementados hoje podem ultrapassar seus objetivos originais, sendo reutilizados na forma de componentes empresariais virtualizados, gerenciados como “caixas pretas” acessadas através de interfaces padronizadas.

ARQUITETURA ORIENTADA A SERVIÇOS - SOA E WEBSERVICES

146

Um exemplo de sistema crítico de difícil modificação são os que executam em mainframes na área bancária. Considerando o impacto monetário de apenas um dia parado, esses sistemas não permitem uma fácil substituição, e a criação de uma camada de chamadas via serviços, para acesso via novas tecnologias acaba sendo uma solução muito mais viável e menos arriscada. Com o uso de SOA é possível trabalhar em um mesmo ambiente, e de forma cooperativa, com o uso de componentes CORBA, JEE, Web Services SOAP ou REST, mensagerias, Sockets planos, entre muitos outros. A figura seguinte demonstra a diversidade de tipos de componentes que podem ser acessados em uma arquitetura orientada a serviços, ao ilustrar algumas das conexões disponibilizadas no Oracle SOA Suite. O que garante essa grande conectividade em um ambiente SOA é a presença do ESB (Enterprise Service Bus), apoiado por diversos tipos de Middleware.

ARQUITETURA ORIENTADA A SERVIÇOS - SOA E WEBSERVICES

147

Tendo o SOA como mediador e fornecedor de interface para o consumidor, garante-se o reuso de sistemas legados frente a novas tecnologias. Nessa arquitetura são aproveitados os diversos meios de interoperabilidade, trabalhando de forma conjunta, o que viabiliza a integração de aplicações distintas criadas em praticamente qualquer tecnologia recente ou legada. Em alguns momentos, mais de uma tecnologia pode ser utilizada para acessar determinada informação. Por exemplo, um mainframe poderia ser acessado via JEE, e as informações disponibilizadas dentro do SOA através de Web Services, o que permitiria a outras plataformas, como dotNet, gerar clientes (consumers) para os serviços providos pelo servidor. Em outras situações podem ser utilizadas mensagerias para a comunicação com outros sistemas, o que é muito comum na área financeira, o que permite

ARQUITETURA ORIENTADA A SERVIÇOS - SOA E WEBSERVICES

148

integrar o ambiente já existente de troca de mensagens com sistemas legados de armazenagem desses dados, como mainframes via JEE, ou disponibilizar para o público externo as informações pertinentes sem a perda da segurança no acesso aos dados tramitados no ambiente da mensageria. Esse tipo de ambiente, com uso de mensagerias na rede privada, está presente na comunicação entre instituições bancárias distintas, onde as solicitações de transferência de valores são mensagens em formato XML criptografado com chave 3DES, e assinado com chave privada RSA. Outro elemento de grande utilização dentro do ambiente SOA é a conexão com LDAP (Lightweight Directory Access Protocol), o que pode ser interessante para a gestão de certificados digitais e da segurança em conjunto com o JAAS (Java Authentication and Authorization Service). Como um protocolo de aplicação aberto, voltados para a gestão de informações hierarquicamente organizadas, o LDAP é um serviço de diretórios utilizado primordialmente para a gestão de informações pessoais em ambiente corporativo, sendo amplamente utilizado para a obtenção de um logon único dentro de todo o ambiente.

Uso de Web Services Embora a arquitetura orientada a serviços seja um modelo conceitual, a abordagem de Web Services é a mais comum para sua implementação efetiva, o que pode ser observado em praticamente todas as ferramentas de mercado atuais como: Oracle SOA Suite, Microsofts SOA Platform e JBoss Enterprise SOA Platform. Através de Web Services é possível criar blocos funcionais de construção acessíveis

através

de

protocolos

de

Internet

padronizados

de

forma

independente de plataformas e linguagens de programação. Esses serviços

ARQUITETURA ORIENTADA A SERVIÇOS - SOA E WEBSERVICES

149

podem representar tanto novas aplicações quanto apenas invólucros em torno dos sistemas legados existentes para disponibilizá-los no ambiente. Neste tipo de abordagem, dois elementos principais deverão ser considerados, os quais são o Service Provider (provedor do serviço) e o Consumer (consumidor). Service Provider - O provedor cria um Web Service e, eventualmente, publica sua interface e acesso à informação para o registro de serviços. Cada fornecedor deve decidir quais serviços irá expor, como balancear entre aspectos de segurança e facilidade de acesso. Também deve decidir em qual categoria os serviços devem ser listados em um dado Broker e que tipo de contrato será definido para a utilização do serviço. Ele registra os serviços e as listas de todos os perfis de acesso permitidos. Alguns Brokers são especializados em muitas listas, enquanto outros oferecem altos níveis de confiança nos serviços listados. Alguns cobrem um amplo panorama de serviços e outros têm foco dentro de uma indústria específica. O Universal Description Discovery and Integration (UDDI) define uma maneira de publicar e descobrir informações sobre os serviços da Web. Outros serviços incluem (por exemplo) ebXML (Electronic Business utilizando eXtensible Markup Language) e aqueles baseados na ISO/IEC 11179 Metadata Registry (MDR) padrão. Consumer - O consumidor de serviços, ou cliente do Web Service, localiza entradas no registro do Broker para encontrar as operações e, em seguida, ligase ao prestador do serviço para invocar um de seus Web Services. Seja qual for o serviço que os consumers precisam, eles têm que solicitá-lo ao Broker e, em seguida, conectar com o respectivo serviço e usá-lo. Consumers podem acessar vários serviços, se estiverem disponíveis. É interessante observar que um provedor pode ser consumidor de outro provedor, e que várias operações só poderão ser efetuadas quando combinados vários serviços através de orquestrações bem-definidas.

ARQUITETURA ORIENTADA A SERVIÇOS - SOA E WEBSERVICES

150

Quando esses agrupamentos ocorrem, para o usuário final fica disponível apenas o Web Service de solicitação primário, ou seja, a interface de serviços para comunicação com o usuário atua como fachada para todos os demais serviços envolvidos. Outra observação é a de que, mesmo que um Web Service possa ser disponibilizado diretamente, sem o uso do Broker, o ideal é que o faça através de outro Web Service disponibilizado pelo mesmo, de forma a não diminuir os aspectos de segurança e governança da arquitetura orientada a serviços.

Atividade proposta Como atividade de fixação, instale o Oracle SOA Suite e faça uma análise das diversas opções de integração oferecidas por esta plataforma SOA. O download do produto está disponível no seguinte endereço: http://www.oracle.com/technetwork/middleware/soasuite/downloa ds/index.html

Referências Saudate, A. SOA aplicado: Integrando com web services e além. Editora Casa do Código, 2012. Hirama, K. Fugita, H. Soa - Modelagem, Análise e Design. Editora Campus, 2012. Kaufman, M. Halper, F. Arquitetura Orientada a Serviços – SOA Para Leigos. Editora Alta Books, 2009.

ARQUITETURA ORIENTADA A SERVIÇOS - SOA E WEBSERVICES

151

Exercícios de fixação Questão 1 Considerando-se a abordagem de Web Services para uma Arquitetura Orientada a Serviços, o que são o OASIS ebXML e UDDI? a) Protocolos de comunicação de Web Services. b) Descritores de Serviços. c) Repositórios de informações relacionados à publicação de descoberta. d) Gestores de segurança. e) Ferramentas de autenticação e autorização de usuários e componentes. Questão 2 Em termos do SOA, analise as seguintes afirmativas: I - Um serviço é definido como uma função independente e sem estado (stateless). II – Os serviços devem se comunicar através de uma interface padronizada e bem definida. III - Um serviço deve ser consumível de forma prática, com ferramentas para descoberta e uso automatizado. IV – A única desvantagem deste tipo de ambiente é o grande aumento do acoplamento. Quantas afirmativas estão corretas? a) Todas estão corretas. b) Apenas uma está correta. c) Apenas duas estão corretas. d) Apenas três estão corretas. e) Nenhuma está correta. Questão 3 Um ambiente SOA deve ser independente de plataforma, conferindo a característica de: a) baixo acoplamento b) neutralidade

ARQUITETURA ORIENTADA A SERVIÇOS - SOA E WEBSERVICES

152

c) coesão d) segurança e) governança Questão 4 Qual dos elementos abaixo NÃO está relacionado aos aspectos de segurança em ambientes SOA? a) Confidencialidade b) Autenticação c) Interoperabilidade d) Autenticidade e) Autorização Questão 5 Outra característica desejável em ambientes SOA é a possibilidade de gestão de políticas e processos necessários à boa utilização da arquitetura, com a definição de papéis e determinação de objetivos claros. A descrição se refere a qual característica específica? a) baixo acoplamento b) neutralidade c) coesão d) segurança e) governança Questão 6 O que viabiliza a grande conectividade do SOA é a presença de um componente principal denominado: a) SOAP b) XML c) JDBC d) RMI e) ESB

ARQUITETURA ORIENTADA A SERVIÇOS - SOA E WEBSERVICES

153

Questão 7 Existem diversos tipos de conectores disponíveis nas plataformas SOA. Entre as opções seguintes, qual delas NÃO é um conector que satisfaça à filosofia de utilização do SOA? a) SOAP b) REST c) CORBA d) Mensagerias e) JDBC Questão 8 Existem várias técnicas que podem ser utilizadas para o reaproveitamento ou adaptação de sistemas legados. No caso de ambientes SOA, a técnica utilizada seria: a) Refatoramento b) Modernização do tipo "caixa preta" c) Modernização do tipo "caixa branca" d) Herança e) Substituição Questão 9 Uma necessidade bastante comum em ambientes SOA é a gestão de segurança, e parte da solução envolve a utilização de certificados digitais, como os do tipo RSA. Qual conector do SOA estaria relacionado ao acesso a estes certificados em grande parte dos sistemas corporativos? a) CORBA b) RPC c) Mensagerias d) RMI e) LDAP

ARQUITETURA ORIENTADA A SERVIÇOS - SOA E WEBSERVICES

154

Questão 10 Com relação à abordagem de Web Services para ambientes SOA, considere as seguintes afirmativas: I – Os dois principais papéis utilizados são Service Provider e Consumer. II – Um provedor não pode ser consumidor de outro provedor. III – Podem ser combinados vários serviços através de processos de orquestração. IV – Sempre que possível o Web Service deve ser acessado diretamente, sem a real necessidade de uso do broker. Quantas das afirmativas estão corretas? a) Todas estão corretas. b) Apenas uma está correta. c) Apenas duas estão corretas. d) Apenas três estão corretas. e) Nenhuma está correta.

ARQUITETURA ORIENTADA A SERVIÇOS - SOA E WEBSERVICES

155

Aula 7 Exercícios de fixação Questão 1 - C Justificativa: Exemplos de repositórios são o OASIS ebXML e UDDI, tratando de ferramentais onde podem ser armazenados e gerenciados artefatos como XML Schemas e WSDL. Estes repositórios não tratam de aspectos relacionados à autenticação e demais elementos relacionados à segurança da plataforma. Quanto ao protocolo normalmente adotado, é o SOAP, e o descritor de serviços mais comum é o WSDL. Questão 2 - D Justificativa: Apenas a afirmativa IV está incorreta. Um termo muito utilizado em termos de programação é "acoplamento ", que trata do nível de interdependência entre os módulos de um sistema. Uma das características do SOA é justamente o baixo acoplamento, e o módulo é considerado coeso quando possui uma atividade bem definida e um baixo acoplamento. Questão 3 - B Justificativa: Apesar de todas as características apresentadas serem desejáveis em um ambiente SOA, a independência de plataforma é denominada neutralidade. Questão 4 - C Justificativa: A interoperabilidade é uma premissa básica para o SOA, porém não faz parte dos aspectos de segurança desejados, como as demais opções, inclusive aumentando a complexidade para que essas sejam implementadas efetivamente.

ARQUITETURA ORIENTADA A SERVIÇOS - SOA E WEBSERVICES

156

Questão 5 - E Justificativa: Apesar de todas as características apresentadas serem desejáveis em um ambiente SOA, esta gestão de papéis e da boa utilização do ambiente é denominada governança. Questão 6 - E Justificativa: O que garante a grande conectividade em um ambiente SOA, viabilizando inclusive o reuso de sistemas legados, é a presença do ESB (Enterprise Service Bus), apoiado por diversos tipos de Middleware. Questão 7 - E Justificativa: Apenas o JDBC não poderia ser considerado um conector típico para SOA. Apesar de ser um middleware para acesso a bases de dados, o SOA se preocupa com o acesso e orquestração de serviços, não tendo como objetivo o acesso direto aos dados de uma determinada base. Este acesso seria intermediado por um componente como o JEE ou Web Service. Questão 8 - B Justificativa: No caso do SOA é utilizada a modernização do tipo "caixa preta", a qual envolve apenas a análise de entradas e saídas do sistema legado dentro de um contexto operacional, de forma a identificar as interfaces desse sistema, ou seja, aproveitando os serviços oferecidos pelo mesmo. Não ocorre qualquer tipo de refatoramento, o que alteraria o código original, nem de extensões na linguagem original, tipicamente por herança, como ocorre na modernização "caixa branca". Finalmente, o uso de SOA é justificado em parte pela impossibilidade de substituição do sistema legado. Questão 9 - E Justificativa: Incialmente, CORBA, RPC e RMI estariam relacionados à conexão com serviços distribuídos, alguns deles considerados legados, e as Mensagerias estão relacionadas ao tratamento de solicitações de forma assíncrona.

ARQUITETURA ORIENTADA A SERVIÇOS - SOA E WEBSERVICES

157

Finalmente, um elemento de grande utilização dentro do ambiente SOA é a conexão com LDAP (Lightweight Directory Access Protocol), o que pode ser interessante para a gestão de certificados digitais e da segurança em conjunto com tecnologias como o JAAS (Java Authentication and Authorization Service). Questão 10 - C Justificativa: As opções II e IV estão incorretas. Um provedor pode ser consumidor de outro provedor, e mesmo que um Web Service possa ser disponibilizado diretamente, sem o uso do Broker, o ideal é que o faça através de outro Web Service disponibilizado pelo mesmo, de forma a não diminuir os aspectos de segurança e governança da arquitetura orientada a serviços.

ARQUITETURA ORIENTADA A SERVIÇOS - SOA E WEBSERVICES

158

Introdução As arquiteturas orientadas a serviços apresentam componentes comuns, cujas funcionalidades devem ser compreendidas corretamente, no intuito de melhor aproveitar as características desse tipo de ambiente. Termos como ESB, BPMN e BPEL são comuns no que se refere ao controle, composição e exposição de serviços, sendo necessário compreender a modelagem de processos e o uso de linguagens e notações específicas para a orquestração dos diversos serviços e recursos. Ferramentas como Oracle SOA Suite, IBM SOA Foundation e JBoss Enterprise SOA Platform encontram nesses termos um vocabulário e funcionalidades comuns. Objetivo: 1. Compreender a importância de elementos como ESB e Middleware; 2. Apresentar o conceito de Orquestração de Serviços e uso do BPMN e do BPEL.

Conteúdo ESB e middleware Quando falamos de middleware, ou “software intermediário”, estamos nos referindo a tecnologias que permitem a criação de uma camada intermediária para a comunicação de dois ou mais componentes de software.

ARQUITETURA ORIENTADA A SERVIÇOS - SOA E WEBSERVICES

159

O middleware normalmente é utilizado para isolar o nível de Back-End do FrontEnd, garantindo a independência com relação ao fornecedor do Back-End, como no caso do banco de dados, onde as opções as mais diversas, incluindo Oracle, MySQL, DB2, Informixsão , Jasmine, Postgre SQL, SQL Server, entre outros.

Com a utilização de um middleware é possível generalizar as soluções de software, aumentando a reutilização de um dado componente em ambientes diversos. A figura seguinte demonstra o uso de algumas famílias de middlewares de acesso a banco de dados por diferentes ferramentas. De um ponto de vista mais amplo, vários elementos podem ser considerados middleware, como por exemplo: 

Remote Procedure Call (RPC)

—

Requisita a execução de

procedimentos remotos.

ARQUITETURA ORIENTADA A SERVIÇOS - SOA E WEBSERVICES

160



Message Oriented Middleware (MOM) — Fornece acesso a um serviço de mensagens.



Object Request Broker (ORB) — Possibilita a comunicação com envio de objetos e solicitações.



SQL-oriented Data Access — Deixa transparente o acesso a bancos de dados.

Metodologia de comunicação Nas

arquiteturas

orientada

a

serviços,

onde

sistemas

heterogêneos

disponibilizam componentes com protocolos de comunicação distintos, existe uma grande dependência da utilização de middleware com as mais diversas finalidades. Em arquiteturas tradicionais do tipo ponto a ponto, a comunicação direta entre aplicações poderá levar o sistema como um todo ao colapso, já que a complexidade da integração cresce de forma exponencial. Com quatro servidores se comunicando dessa forma ocorrerão seis possibilidades de conexão, enquanto com seis servidores o número sobe para quinze conexões, e dentro de um ambiente corporativo, como dezenas e até centenas de servidores cooperando, essa arquitetura acaba sendo inviável. Baseando-se nas informações anteriores, foi concebida uma nova metodologia de comunicação entre sistemas por meio de um canal centralizador, algo próximo do que ocorre no uso de mensagerias, porém aqui sendo tratados serviços e componentes heterogêneos. Com isso, surge o termo ESB (Enterprise Service Bus), referente à camada de middleware de negócios de uma arquitetura orientada a serviços. Basicamente trata do núcleo da arquitetura, agrupando todas as tecnologias de comunicação

ARQUITETURA ORIENTADA A SERVIÇOS - SOA E WEBSERVICES

161

com os diversos tipos de componentes suportados pelo software gestor dessa arquitetura.

Atenção A palavra "bus" (barramento) é uma referência ao meio físico que carrega bits entre dispositivos em um computador. O ESB provê uma função análoga em alto nível de abstração.

Considerando uma arquitetura empresarial que faça uso de um ESB, uma aplicação irá se comunicar via barramento, que atua como um message broker entre aplicações. A principal vantagem dessa abordagem é a redução de conexões ponto a ponto necessárias para permitir a comunicação entre aplicações. Isso, por sua vez, afeta diretamente a simplificação da manutenção do sistema, pois ao reduzir o número de conexões ponto a ponto para uma aplicação específica, o processo de adapatação desse sistema às mudanças em um de seus componentes torna-se mais fácil.

Adoção de um ESB

ARQUITETURA ORIENTADA A SERVIÇOS - SOA E WEBSERVICES

162

A adoção de um ESB promove grande atomicidade para os serviços, e com isso, se um sistema tiver de ser reescrito, particionado ou qualquer outro tipo de mudança, é através do barramento que será resolvida a comunicação, mantendo-se intactas as interfaces dos demais sistemas envolvidos.

Atenção Normalmente

um

ESB

apresenta

grande

complexidade,

envolvendo todo o ferramental necessário para o acesso a ambientes

heterogêneos,

onde

podem

estar

presentes

mainframes, bancos de dados, serviços SOAP e REST, sockets, mensagerias, entre muitos outros elementos.

Aplicação do ESB Com o uso do ESB é possível integrar em um mesmo ambiente, mantendo a independência de cada componente, dados, fluxos de execução, serviços de forma geral, B2B, ferramentas de publicação para portais, aplicações legadas e novos elementos de software, como pode ser visto na figura seguinte:

ARQUITETURA ORIENTADA A SERVIÇOS - SOA E WEBSERVICES

163

Como exemplo de arquitetura comercial de um ESB, a figura apresentada representa a composição do JBoss ESB. As funções principais de um ESB são: ARQUITETURA ORIENTADA A SERVIÇOS - SOA E WEBSERVICES

164



Monitorar e controlar o roteamento das mensagens trocadas entre serviços.



Resolver disputa na comunicação entre componentes de serviço.



Controlar a implantação e o versionamento de serviços.



Conduzir o uso de serviços redundantes.

Atender a serviços corporativos compartilhados, como a manipulação de eventos, transformação de dados e mapeamento, mensagem e evento filas e sequenciamento, manipulação de segurança ou exceção, conversão de protocolo e gerenciamento adequados da qualidade de serviço de comunicação. Além da grande diversidade de middleware presente no ESB, a gerência do fluxo de chamadas e respostas deve ser feita segundo um processo de composição e orquestração de serviços. Muitas vezes, ocorre uma grande confusão entre orquestração e coreografia de serviços. Em termos de orquestração existe um ambiente mediador, sendo a ativação e coordenação das diversas chamadas e respostas sempre efetuadas através dele, enquanto que para a coreografia não existe esse coordenador central, e por consequência todos os participantes se conhecem e atuam de forma colaborativa.

Atenção Para efetuar a coreografia de serviços 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 serviço, a orquestração com uso de BPEL (Business Process Execution Language) torna-se mais efetiva.

ARQUITETURA ORIENTADA A SERVIÇOS - SOA E WEBSERVICES

165

Orquestração de serviços A orquestração de serviços é definida como o processo de sequenciar serviços e prover uma lógica adicional para processar dados, não incluindo uma representação desses dados. Essa orquestração é facilitada com o uso de notações gráficas e linguagens específicas. No mercado dos BPMS (Business Process Management Systems, ou Sistemas de Gerenciamento de Processos de Negócios), verifica‐se a existência de duas tendências 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 execução, ficando assim mais próximo da implementação. Com relação ao BPMN, ele traz uma grande aceitação por tratar de uma notação gráfica para a representação de processos de negócio. A adoção desses dois ferramentais é comum no SOA, e enquanto essas ferramentas possibilitam atingir a excelência nos processos, padronização e automação, a arquitetura de execução do SOA viabiliza grande reutilização, governança e segurança.

ARQUITETURA ORIENTADA A SERVIÇOS - SOA E WEBSERVICES

166

Um exemplo de uso pode ser observado ao lado, com a definição de um processo que envolve a chamada a um Web Service externo em BPEL 2.0, dentro do ambiente gráfico do Oracle SOA Suite.

BPMN Quando falamos de BPMN nos referimos a uma notação gráfica utilizada para representar processos de negócio, sendo a mesma composta por um conjunto de símbolos padronizados, os quais são organizados em um diagrama de processos de negócio. O objetivo do BPMN é comunicar informações diversas com diferentes públicos de forma organizada. Entre os envolvidos podem ser encontrados: analistas de negócio, desenvolvedores e interessados nos processos de forma geral (gerentes, coordenadores etc.). Elementos básicos do BPMN: 

Eventos, tratando de elementos que afetam o fluxo do processo de negócio.



Atividades, referindo-se a comandos executados durante o processo, podendo ser atômicas ou compostas.



Gateway, o qual controla a convergência ou divergência do fluxo.

Evento Ocorrência que dispara uma atividade e são categorizadas pelo tipo (início, intermediário e fim) e pelo gatilho (nenhum, mensagem, temporizador, condicional, sinal, exceção, cancelamento, compensação, ligação, múltiplo ou terminação). O símbolo básico de um evento é um pequeno círculo que pode ser complementado pelo seu tipo e seu gatilho; o início é representado por uma borda fina; o evento intermediário é representado por uma borda dupla; e o evento de fim é representado por uma borda espessa.

ARQUITETURA ORIENTADA A SERVIÇOS - SOA E WEBSERVICES

167

Atividade Trabalho executado dentro de um processo de negócio podendo ser atômico ou não atômico (composto). Atividades que fazem parte de um diagrama de processos de negócio são classificadas como: processos, subprocessos ou tarefas. O processo em si não é um objeto gráfico específico, mas um conjunto de objetos gráficos. Tarefa (Task) - Atividade atômica que é incluída dentro de um processo. É usada quando o trabalho em um processo não é quebrado em um nível menor de detalhe do modelo de processo. Subprocesso (Sub-Process) - Atividade composta que possui detalhes definidos por uma sequência de outras atividades. Pode ser observado como um objeto gráfico dentro de um fluxo de processo, mas possibilita a expansão para exibir outro processo embutido ou reutilizável. Para determinar o fluxo do processo, as atividades e os eventos são relacionados através de objetos de conexão específicos.

ARQUITETURA ORIENTADA A SERVIÇOS - SOA E WEBSERVICES

168

Gateway

Gateways são elementos utilizados para controlar a convergência ou divergência do fluxo ao longo de sua execução. Se o fluxo não precisa ser controlado, não precisamos utilizar Gateways, pois os mesmos são opcionais. Toda a simbologia aqui utilizada foi definida nas normatizações 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 negócio. Cada Pool poderá envolver vários processos, porém pode ser necessário trabalhar com uma divisão maior, ao nível da estrutura interna da empresa, sendo utilizadas divisões denominadas Lanes. ARQUITETURA ORIENTADA A SERVIÇOS - SOA E WEBSERVICES

169

Pool é utilizado para separar dois participantes de um processo de negócios fisicamente separados, sendo a comunicação entre os mesmos através de mensagens. Lane é uma divisão dentro de um pool, identificando participantes dentro de uma mesma organização. Em termos de governança, o uso de BPMN permite um olhar muito organizado sobre os processos de negócio da empresa, trazendo os requisitos necessários para a definição dos diversos modelos dos processos de negócios, e viabilizando o mapeamento para a implementação BPEL adequada, como propõe a figura seguinte.

ARQUITETURA ORIENTADA A SERVIÇOS - SOA E WEBSERVICES

170

BPEL A linguagem BPEL tem como objetivo efetuar a orquestração da chamada de serviços, segundo uma sintaxe baseada em XML, sendo voltada para Web Services, isto devido às atuais características dos diversos provedores para SOA. Historicamente, IBM e Microsoft definiram, respectivamente, as linguagens de orquestração de serviços: 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 consórcio formado por BEA Systems, IBM, Microsoft, SAP e Siebel Systems apresentou o BPEL4WS 1.1 à OASIS para a normalização. Em 14 de setembro de 2004 ocorre a alteração do nome para "WS-BPEL 2.0", incluindo diversas melhorias, sendo hoje comumente denominado BPEL 2.0 Apesar de alinhada com uma interpretação gráfica bastante próxima do BPMN, a sintaxe BPEL não precisa de diagramas, mas simplesmente do uso de XML. ARQUITETURA ORIENTADA A SERVIÇOS - SOA E WEBSERVICES

171

Alguns dos elementos que podem ser encontrados em um arquivo BPEL podem ser visualizados na tabela seguinte.

Estes são apenas alguns dos elementos presentes na sintaxe. Em verdade BPEL é uma linguagem muito rica, com vários recursos voltados para o controle, sequenciamento e comunicação de serviços. O código-fonte BPEL para a notação gráfica

















ARQUITETURA ORIENTADA A SERVIÇOS - SOA E WEBSERVICES

175

Atividade proposta Baseado no exercício anterior, acerca de Web Services, será criado um processo BPEL no Oracle SOA Suite. Caso não tenha efetuado o exercício, crie agora um Web Service de calculadora com as quatro operações básicas através 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 serviço que efetuará o cálculo de saldo baseado em juros simples ou compostos, o que deve ocorrer através de um processo de orquestração de chamadas ao Web Service de calculadora.

Observação:

Onde C = Capital Inicial, t = Taxa de Juros, n = Período.

ARQUITETURA ORIENTADA A SERVIÇOS - SOA E WEBSERVICES

176

Referências Saudate, A. SOA aplicado: Integrando com web services e além, Editora Casa do Código, 2012. Hirama, K. Fugita, H. Soa - Modelagem, Análise e Design. Editora Campus, 2012. Kaufman, M. Halper, F. Arquitetura Orientada a Serviços – SOA Para Leigos. Editora Alta Books, 2009. 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

ARQUITETURA ORIENTADA A SERVIÇOS - SOA E WEBSERVICES

177

Exercícios de fixação Questão 1 Na arquitetura SOA, o acesso aos diversos tipos de tecnologias englobados é feito por intermédio da estrutura denominada: a) RPC b) ESB c) CORBA d) RMI e) JEE Questão 2 "Quando trabalhamos com serviços de forma colaborativa existem duas formas de organizá-los e sequenciá-los. Na prática denominada ___________ existe um ambiente mediador, sendo a ativação e coordenação das diversas chamadas e respostas sempre efetuadas através deste, enquanto que no modelo denominado ______________ não existe este coordenador central, e por consequência todos os participantes se conhecem e atuam de forma colaborativa." Qual opção completa corretamente as lacunas? a) Coreografia e broadcast. b) Coreografia e orquestração. c) Coreografia e ESB. d) Orquestração e ESB. e) Orquestração e coreografia. Questão 3 Qual o nome adotado para a camada intermediária entre dois ou mais componentes de software? a) Front-end b) ESB c) Middleware d) Back-end

ARQUITETURA ORIENTADA A SERVIÇOS - SOA E WEBSERVICES

178

e) MOM Questão 4 Como núcleo da Arquitetura Orientada a Serviços, o ESB cumpre com várias tarefas referentes aos serviços. Qual das opções abaixo NÃO é uma destas tarefas? a) Transformação b) Roteamento c) Gerência d) Segurança e) Implementação Questão 5 Considere as seguintes afirmativas: I – A linguagem BPEL é amplamente utilizada na orquestração de serviços. II – Outra opção de linguagem para efetuar a orquestração é a WS-CDL. III – Toda a comunicação do ESB com outras tecnologias deve utilizar Web Services. Qual das opções está correta? a) Apenas a afirmativa I é verdadeira. b) São verdadeiras as afirmativas II e III. c) Apenas a afirmativa II é falsa. d) Todas as afirmativas são verdadeiras. e) Todas as afirmativas são falsas. Questão 6 Os elementos básicos fornecidos pelo BPMN para a modelagem de processos são: a) Eventos, Atividades e Tarefas. b) Eventos, Tarefas e Gateways. c) Eventos, Tarefas e Subprocessos. d) Atividades, Tarefas e Subprocessos.

ARQUITETURA ORIENTADA A SERVIÇOS - SOA E WEBSERVICES

179

e) Eventos, Atividades e Gateways. Questão 7 Considere as afirmativas acerca do seguinte fluxo de processo:

I – "Lottery Retailer " e "Customer " são pools, definindo duas instituições diferentes. II – "Wait for result" é um evento simples. III – O processo todo é iniciado por "Order received". Qual das opções é verdadeira? a) Todas as afirmativas estão corretas. b) As afirmativas II e III estão corretas. c) Apenas a afirmativa I está correta. d) As afirmativas I e II estão corretas. e) Nenhuma afirmativa está correta. Questão 8 Segundo a BPMN, o que significa o símbolo abaixo?

ARQUITETURA ORIENTADA A SERVIÇOS - SOA E WEBSERVICES

180

a) Atividade Ad-hoc. b) Subprocesso que repete a si próprio (loop). c) Tarefa que repete a si própria (loop). d) Tarefa de compensação. e) Subprocesso de múltiplas instâncias. Questão 9 Em termos de BPEL, quais comandos fazem, respectivamente, a chamada a um serviço e a recepção 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. Questão 10 Qual comando BPEL deve ser utilizado quando precisamos escolher uma entre várias atividades? a) process b) throw c) terminate d) switch e) while

ARQUITETURA ORIENTADA A SERVIÇOS - SOA E WEBSERVICES

181

Aula 8 Exercícios de fixação Questão 1 - B Justificativa: O termo ESB (Enterprise Service Bus), refere-se à camada de middleware de negócios de uma arquitetura orientada a serviços. Basicamente trata do núcleo da arquitetura, agrupando todas as tecnologias de comunicação com os diversos tipos de componentes suportados pelo software gestor desta arquitetura. As demais opções apresentadas tratam justamente de tecnologias que costumam ser acessadas por intermédio do ESB nesta arquitetura. Questão 2 - E Justificativa: A orquestração de serviços exige um mediador central, o qual normalmente é constituído do ESB e ferramentas de apoio no SOA, enquanto a coreografia não trabalha com este mediador, trazendo um ambiente em que os serviços colaboram diretamente uns com os outros. Questão 3 - C Justificativa: Quando falamos de middleware estamos nos referindo a tecnologias que permitem a criação de uma camada intermediária para a comunicação de dois ou mais componentes de software. O middleware normalmente é utilizado para isolar o nível de Back-End do FrontEnd, sendo o MOM um exemplo de tipo de middleware específico para mensagerias. Quanto ao ESB, ele precisa de grande diversidade de middlewares para garantir toda a interoperabilidade desejada. Questão 4 - E Justificativa: O ambiente SOA se preocupa com a gerência, segurança e orquestração de serviços, mas não com a implementação dos mesmos, fato este que garante a grande neutralidade deste ambiente.

ARQUITETURA ORIENTADA A SERVIÇOS - SOA E WEBSERVICES

182

Questão 5 - A Justificativa: A afirmativa II é falsa, pois WS-CDL é uma linguagem para coreografia de serviços, e não orquestração. Quanto à afirmativa III, o ESB concentra uma grande gama de middleware para acesso a diferentes tipos de tecnologias, logo não ficando restrito aos Web Services. Questão 6 - E Justificativa: Elementos básicos do BPMN: - Eventos, tratando de elementos que afetam o fluxo do processo de negócio. - Atividades, referindo-se a comandos executados durante o processo, podendo ser atômicas ou compostas. - Gateway, o qual controla a convergência ou divergência do fluxo. Questão 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 dependência de "Buy a ticket". Questão 8 - B Justificativa: A simbologia das atividades pode ser observada a seguir. O símbolo de "+" indica um subprocesso fechado (fora da forma expandida), e a simbologia utilizada é a de loop.

ARQUITETURA ORIENTADA A SERVIÇOS - SOA E WEBSERVICES

183

Questão 9 - A Justificativa: Os comandos são invoque e receive, como pode ser observado nos descritivos abaixo.

Questão 10 - D Justificativa: O comando é switch, como pode ser observado nos descritivos abaixo.

ARQUITETURA ORIENTADA A SERVIÇOS - SOA E WEBSERVICES

184

Rogério Leitão Nogueira é Mestre em Educação Tecnológica, Pós graduado em Docência 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 Informação da FAETERJ Paracambi - FAETEC.

ARQUITETURA ORIENTADA A SERVIÇOS - SOA E WEBSERVICES

185