ALANYAZIN TARAMASININ SONUCU

De forma a permitir que aplicações clientes desenvolvidas com linguagens de programação diferentes e hospedadas em dispositivos com arquitetura de hardware e software diferentes possam acessar o mesmo ponto de publicação de um determinado serviço, optamos por desenvolver estes serviços através de uma tecnologia que seja capaz de balancear os benefícios de interoperabilidade entre plataformas diferentes sem agregar tamanha latência que impacte na interação homem-máquina.

Atualmente, a tecnologia de comunicação inter-processo que melhor atende essa necessidade é a implementação de Web Services. Nesse modelo de programação, geralmente é utilizado o protocolo SOAP para troca de informações e a linguagem WSDL é usada para descrever a interface desses serviços. Em tal infraestrutura, os Web Services podem ser acessados diretamente pelas aplicações clientes e podem ser combinados, formando uma aplicação composta.

110

A peça central na arquitetura Web Services é a linguagem XML, a qual permite a codificação de dados binários em um documento de texto. O protocolo SOAP é baseado na linguagem XML e é constituído de três elementos [74]: Envelope, Header e Body. O Envelope é o elemento raiz de uma mensagem, contendo um campo opcional, o Header, e um campo obrigatório, o Body. O elemento Header oferece uma estrutura flexível para especificar requisitos adicionais no nível da aplicação. Por exemplo, o elemento Header pode prover um mecanismo para gerenciamento de transações e autenticação/autorização. Já no elemento Body está contido o payload, ou seja, as informações efetivas de interesse da aplicação. Os serviços e operações providas são descritos na linguagem WSDL, que é baseada em XML Schema, provendo os elementos básicos para que uma aplicação cliente interaja com um Web Service, tais como localização do serviço e especificação do mecanismo de transporte utilizado para troca de mensagens. A arquitetura de Web Services é independente do protocolo de transporte, podendo utilizar protocolos tais como HTTP, SMTP, FTP, dentre outros.

Enquanto o protocolo SOAP não especifica qual o mecanismo de transporte deve ser utilizado na troca das mensagens entre o cliente e o provedor do serviço, a grande maioria das implementações SOAP que emulam o comportamento de RPC (Remote

Procedure Call) através do par request/replyutilizam o protocolo HTTP.

As implementações do protocolo SOAP diferem entre si, principalmente no que diz respeito à facilidade de uso e ao desempenho. Atualmente, as duas principais tecnologias que implementam o padrão SOAP permitindo o desenvolvimento e hospedagem de aplicações orientadas a serviços através de Web Services são o .NET e o J2EE. Neste trabalho, foram desenvolvidas e disponibilizadas algumas interfaces para o usuário acessar o sistema, sendo que a maioria delas utiliza tecnologia Web Services. A tabela 7 consolida os tipos de interfaces disponibilizadas aos usuários do sistema, a tecnologia que dá suporte para a execução dessa interface no dispositivo hospedeiro, a tecnologia envolvida para essa aplicação cliente se comunicar com o nodo gatewaye o protocolo de comunicação utilizado nessa comunicação é apresentada a seguir.

Interfaces Gráficas Plataforma Tecnologia Protocolo / Formatação

111 Aplicações Web Independente Aplicação Web HTTP

Aplicações Móveis Telefone Celular

J2ME Web Services HTTP / Formato SOAP

Aplicações Móveis

Smartphones e PDA’s

.NET Web Services HTTP / Formato SOAP

Tabela 8: Aplicações clientes, tecnologias e protocolos de comunicação envolvidos

Como podemos observar, a maioria das aplicações clientes se comunicam com os serviços através de Web Services. Dessa forma, é importante que o provedor do serviço seja desenvolvido utilizando uma tecnologia que melhor implemente o padrão SOAP em termos de escalabilidade e desempenho. Para isso, torna-se fundamental comparar o desempenho dos serviços implementados e hospedados com tecnologia .NET vs. tecnologia J2EE.

Assim, foram realizados dois testes. No primeiro teste, os Web Services e os serviços de negócio foram implementados e hospedados usando tecnologia .NET. No segundo teste, foi utilizada tecnologia J2EE para implementar os Web Services e os serviços de negócio e o IBM Web Sphere 6.1 para hospedá-los. Na tecnologia .NET, os Web Services comunicam-se com os serviços de negócio através do WCF. Por outro lado, na tecnologia J2EE, os Web Services comunicam com os serviços internos através de Java RMI [75]. Nos dois testes foram executados o métodos remoto sendCommand, introduzido no Capítulo 6.

O gráfico da figura 39 ilustra os resultados obtidos para a execução do experimento, que executou o método sendCommand iterativamente durante um período de 20 minutos, utilizando tecnologia .NET e tecnologia J2EE.

Figura 39: Métricas de desempenho (TPS) da aplicação desenvolvida e hospedada com tecnologia J2EE vs tecnologia .NET

112

Nestes experimentos, foi utilizada a forma de Conexão Direta (apresentada no quarto capítulo) sem utilizar a infraestrutura SOA, tais como os serviços de ESB (virtualização, roteamento, transformação de mensagem, verificação do contexto de segurança), de localização dos serviços através do Service Registry, etc. Pode-se notar que o desempenho da tecnologia .NET foi superior ao desempenho da tecnologia J2EE. A tecnologia .NET apresentou uma média de 18 TPS (Transações Por Segundo) enquanto que a aplicação desenvolvida e hospedada com tecnologia J2EE apresentou média de 13 TPS. Os resultados apresentados nessa seção justificam a escolha pela tecnologia .NET na proposição da arquitetura orientada a serviços.

As métricas de desempenho apresentadas na figura 39 representam os experimentos efetuados utilizando “Conexão Direta”. No entanto, na proposição da arquitetura SOA, a forma comum de se acessar um serviço de negócio, tal como o serviço que prove o método sendCommand, é através da Conexão Intermediada (utilizando os mecanismos suplementares da arquitetura SOA). Dessa forma, faz-se necessário levantar as métricas de desempenho desse método através da Conexão Intermediada a fim de quantificar a sobrecarga adicionada em decorrência da inclusão dos mecanismos SOA. A figura 40 apresenta as evidências de desempenho para o mesmo experimento efetuado com a tecnologia .NET, alterando apenas a forma de conexão, que agora é Intermediada.

Figura 40: Métricas de desempenho (TPS) da aplicação desenvolvida e hospedada com tecnologia J2EE vs tecnologia .NET

Utilizando a conexão Intermediada a média foi de 10 TPS, uma sobrecarga de 55.55%, em média.

113

Para efetuar os experimentos foi utilizada a ferramenta LoadRunner[77], da Mercury/HP. Essa ferramenta foi configurada para enviar requisições ao nodo gatewayaté que o servidor atinja 100% de utilização dos seus processadores. Os resultados gerados foram consolidados no Excel para gerar os gráficos com as métricas de desempenho.

7.2 Desempenho e escalabilidade dos serviços Multimídia Data Broker / Multimídia Data