XML como Formato de Mensagem, XML Parser e Mensagens SOAP

Em (Andresen et al., 2004) os autores concluem que o maior custo da codificação e decodifi- cação do XML está na complexidade estrutural dos elementos, ao invés de dados das mensagens. Eles mencionam que uma grande percentagem do tempo gasto pelo provedor é na codificação da mensagem XML, no processo de marshalling (o processo de transformar a representação em memória de um objeto para um formato de dados adequado para o armazenamento ou transmis- são). Os autores mostram uma lista de verificação que é importante considerar, principalmente se o foco é a construção ou integração de sistemas com restrições de avaliação de desempenho. É importante considerar esta listagem e também as medidas relacionadas ao processamento de mensagens SOAP (Andresen et al., 2004):

• Chamadas SOAP têm uma grande sobrecarga, devido ao tempo de execução considerável exigido para processar mensagens XML.

• Não há equilíbrio entre a velocidade de execução e interoperabilidade.

• Cinqüenta por cento do tempo de execução é gasto na codificação de dados XML e na cri- ação de uma conexão HTTP. A codificação XML envolve: preparação da carga útil SOAP e a serialização e marshalling da carga útil antes desta ser transmitida para o provedor de serviços.

• SOAP é ineficiente em comparação com CORBA e RMI, em computação distribuída • Falta de otimização com dados XML

• Codificação de dados binários na forma de resultados XML e uma sobrecarga de processa- mento

Também é importante mencionar que a sobrecarga de processamento de mensagens SOAP pode estar relacionada a:

• Velocidade de codificação e decodificação: Conversão de dados binários para o padrão

American Standard Code for Information Interchange(ASCII) e vice-versa é um dos prin-

cipais custos relacionados ao processamento de dados XML. Particularmente o alto custo em relação ao desempenho ocorre para valores de ponto flutuante e matrizes de grandes dimensões (Ying et al., 2005).

• Alto Custo da Rede de Transmissão: Os dados ASCII resultantes da decodificação são maiores que o dado binário original. Para transferir dados binários por meio de mensagens

SOAP são usados algoritmos de codificação binária como o base64. A conversão dos ar-

32 3.3. LIMITAÇÕES DO PARADIGMA DE ARQUITETURAS ORIENTADAS A SERVIÇO largura de banda necessária para a transmissão de dados (Zhang et al., 2007). Um cenário típico onde conversão é usada, é na transferência e gestão de dados de experimentos cien- tíficos, que geram grandes quantidades de dados. A transferência de dados binários usando um algoritmo de codificação pode degradar o desempenho do sistema. Em um estudo de avaliação de desempenho foi possível identificar os principais aspectos relacionados à trans- ferência de dados binários dentro de mensagens SOAP utilizando três diferentes técnicas (Binário Puro, e SWA/MTOM), apresentado em (Estrella et al., 2009).

• Tamanho da mensagem: O tamanho da representação de dados SOAP é tipicamente cerca de 10 vezes o tamanho da representação binária equivalente. Isso ocorre particularmente devido aos custos associados à codificação e decodificação de valores de ponto flutuante. Em (Alodib e Bordbar, 2009) é apresentado um método de criação de arquiteturas que per- mitem a monitoração da ocorrência de falha em arquiteturas orientadas a serviço (SOA). A abor- dagem apresentada abrange técnicas de sistemas de eventos discretos para produzir um método de criação automatizada de diagnóstico do serviço que monitora a interação entre os serviços para identificar se uma falha ocorreu e qual é o tipo da falha. Além dos requisitos de segurança e tolerância a falhas, o aspecto desempenho precisa ser considerado em função dos problemas dis- cutidos. Na integração de sistemas em tempo real, por exemplo, a utilização de SOAP e XML não são a melhor opção (Kohlhoff et al., 2004). O uso de SOAP e XML incorrem em uma penalidade de desempenho em comparação com os protocolos binários. Para completar os problemas discutidos em (Andresen et al., 2004), outros fatores podem afetar o desempenho dos Web Services, tais como o desenho e implementação de serviços. Alguns deles são listados em (Mani e Nagarajan, 2002), (Kohlhoff et al., 2004):

• XML Parser: Diferenças em relação à eficiência da memória, velocidade computacional e facilidade de uso. Os parsers se encaixam em duas categorias: baseado em árvore (por exemplo, Document Object Model (DOM) ou baseado em eventos (por exemplo, Stax). Em um parser push-based, o próprio parser tem o controle do fluxo de dados e decide o que fazer com a informação. Em um parser pull-based a aplicação "puxa"os dados do fluxo de dados XML de acordo com sua conveniência. A aplicação e não o parser está no controle, o que dá a aplicação o poder para filtrar, manter tags ou parar o parser a qualquer momento. Em parsers do tipo DOM, todo o conteúdo do documento XML é lido na memória e uma transformação do objeto desse conteúdo é produzida. O principal problema de parsers DOM é a ineficiência do uso de memória, pois toda a informação é analisada. Algumas aplicações não precisam de todas as informações representadas na memória, mas apenas parte dela. Carregar grandes documentos na memória também pode causar problemas de segurança como será discutido mais adiante neste documento. Pull parser é mais eficiente com relação ao uso de memória, pois o código da aplicação controla diretamente o parser iterando sobre o documento usando o leitor de stream baseado em Stax. Outra questão importante é o

CAPÍTULO 3. DESEMPENHO EM SOA E QOS EM WEB SERVICES 33 papel do parser XML no desempenho do protocolo SOAP. Parsers XML causam uma elevada utilização de recursos computacionais quando mensagens XML são processadas.

• WSDL: A interface que permite a descrição de um Web Service específico para o mundo exterior, também apresenta problemas que precisam ser investigados. A WSDL se preocupa apenas com aspectos funcionais e de sintaxe, mas não verifica se a semântica do documento está correta ou se as normas mínimas de QoS podem ser alcançadas. Devido à ausência de tais características, o desenvolvedor precisa compreender as características de QoS dos Web Services, desenvolvendo aplicativos que dependem de Web Services. A WSDL também ex- põe as operações em um domínio sem se preocupar com a segurança, sendo assim suscetível a ataques, conforme descrito em (Jensen et al., 2007).

• Cálculo do Tamanho da Mensagem: Conhecer dinamicamente o conteúdo de uma men- sagem SOAP é difícil sendo necessário na maioria dos casos a utilização de buffers.

• Custos de Estabelecimento de Conexão: Uma nova conexão HTTP para cada operação degrada o desempenho, devido a interação com determinadas características do TCP como:

handshakede três vias e algoritmo de partida lenta. O HTTP 1.0 não é a melhor escolha. A

melhor maneira é utilizar o protocolo HTTP 1.1 com buffering pipelining, porque a conexão por si só não é suficiente para melhorar o desempenho.

• Canal de Comunicação: Um fator limitante no desempenho de Web Services é o canal de comunicação. Deve-se ressaltar que os Web Services atingiram certa maturidade devido ao fato de que a comunicação entre serviços ser feita por meio da Internet. No entanto, detalhes como baixa latência, baixo congestionamento e garantia de entrega devem ser considerados na transmissão de mensagens. Talvez esses detalhes pudessem ser garantidos se uma rede global fosse construída exclusivamente para a Web Services.

• Protocolo de Vinculação de Rede (Binding Protocol): O uso do HTTP deveria ser restrito somente para a comunicação estilo mensagem, uma vez que o HTTP é um protocolo do tipo requisição-resposta. Em sistemas de tempo real, o HTTP não é uma solução adequada. Os problemas discutidos a seguir podem aparecer em algumas das etapas que envolve o processamento de uma mensagem SOAP tanto no cliente como no provedor de serviços (Andresen et al., 2004):

– Recepção da requisição pelo roteador

– Identificação do provedor e o despacho da chamada para o provedor de serviços – Despacho da chamada para o serviço atual e a recepção da resposta subsequente – Marshalling do envelope

34 3.3. LIMITAÇÕES DO PARADIGMA DE ARQUITETURAS ORIENTADAS A SERVIÇO Há outras abordagens na literatura para melhorar o desempenho dos Web Services. As técnicas vão desde o mecanismo de desserialização que reutiliza regiões correspondentes obtidas de objetos previamente desserializados de mensagens anteriores (Suzumura et al., 2005), a implementação do protocolo SOAP utilizando um mecanismo de cache no provedor de serviços (Andresen et al., 2004), dentre outras. Técnicas para enviar dados binários encapsulados em mensagens SOAP (Heinzl et al., 2006) também são discutidas.