Uma Abordagem para Avaliação e Tratamento de Exceções ... · a adoção de técnicas de veri...

Universidade Federal do Rio Grande do Norte

Centro de Ciências Exatas e da Terra

Departamento de Informática e Matemática Aplicada

Programa de Pós-Graduação em Sistemas e Computação

Mestrado Acadêmico em Sistemas e Computação

Uma Abordagem para Avaliação e Tratamento

de Exceções Propagadas no uso de Serviços

Web em .NET

José Alex Medeiros de Lima

Natal-RN

Fevereiro 2015

José Alex Medeiros de Lima

Uma Abordagem para Avaliação e Tratamento de

Exceções Propagadas no uso de Serviços Web em .NET

Dissertação de Mestrado apresentada ao Pro-grama de Pós-Graduação em Sistemas eComputação do Departamento de Informá-tica e Matemática Aplicada da UniversidadeFederal do Rio Grande do Norte como re-quisito parcial para a obtenção do grau deMestre em Sistemas e Computação.

Linha de pesquisa:Engenharia de Software

Orientador

Nélio Alessandro Azevedo Cacho, Dr.

PPgSC � Programa de Pós-Graduação em Sistemas e Computação

DIMAp � Departamento de Informática e Matemática Aplicada

CCET � Centro de Ciências Exatas e da Terra

UFRN � Universidade Federal do Rio Grande do Norte

Natal-RN

Fevereiro/2015

Catalogação da Publicação na Fonte. UFRN / SISBI / Biblioteca Setorial Centro de Ciências Exatas e da Terra – CCET.

Lima, José Alex Medeiros de. Uma abordagem para avaliação e tratamento de exceções propagadas no uso de

serviços Web em .Net / José Alex Medeiros de Lima. - Natal, 2015. 82 f. : il. Orientador: Prof. Dr. Nélio Alessandro Azevedo Cacho. Dissertação (Mestrado) – Universidade Federal do Rio Grande do Norte. Centro

de Ciências Exatas e da Terra. Programa de Pós-Graduação em Sistemas e Computação.

1. Engenharia de software – Dissertação. 2. Serviços web – Dissertação. 3.

Injeção de defeito – Dissertação. 4. Propagação de exceção. I. Cacho, Nélio Alessandro Azevedo. II. Título.

RN/UF/BSE-CCET CDU: 004.41

Dissertação de Mestrado sob o título Uma Abordagem para Avaliação e Tratamento de

Exceções Propagadas no uso de Serviços Web em .NET apresentada por José Alex Me-

deiros de Lima e aceita pelo Programa de Pós-Graduação em Sistemas e Computação

do Departamento de Informática e Matemática Aplicada da Universidade Federal do Rio

Grande do Norte, sendo aprovada por todos os membros da banca examinadora abaixo

especi�cada:

Nélio Alessandro Azevedo Cacho, Dr.Presidente



Roberta de Souza Coelho, Dra.Examinador



Fabiano Cutigi Ferrari, Dr.Examinador

UFSCAR � Universidade Federal de São Carlos

Natal-RN, 27 de Fevereiro de 2015.

À minha esposa, Maria Kalyana Patrícia da Silva, à minha mãe, Maria do Socorro de

Medeiros Lima e à minha irmã, Aline Medeiros de Lima, meus alicerces. Sem elas, não

conseguiria realizar minhas conquistas.

Agradecimentos

Agradeço a Deus por ter me dado força em todos os momentos, principalmente os de

fraqueza e dúvida, permitindo que eu concluísse esta etapa importante da minha vida.

À minha esposa Kalyana, pela compreensão necessária para que eu pudesse concluir este

trabalho. Ao meu orientador Nélio Cacho, pela amizade, disponibilidade, atenção, in-

centivo, oportunidade e pelos ensinamentos acadêmicos que muito contribuíram para o

desenvolvimento deste trabalho. Aos meus colegas de mestrado, pela amizade, brincadei-

ras e por compartilharem comigo dos mesmos desa�os, principalmente ao Arthur Cássio

que muito me ajudou no início do mestrado e ao Frederico Pranto que sempre me escutou

com paciência nos momentos difíceis, sempre com palavras de incentivo.

A história dos homens é um instante entre dois passos de um caminhante.

Franz Kafka

Uma Abordagem para Avaliação e Tratamento deExceções Propagadas no uso de Serviços Web em .NET

Autor: José Alex Medeiros de Lima

Orientador(a): Dr. Nélio Alessandro Azevedo Cacho

Resumo

Alta con�abilidade, disponibilidade e tolerância à falha ainda são problemas em aberto

em arquiteturas orientadas a serviços (SOA). Serviços web consistem em uma implemen-

tação da arquitetura SOA baseada em padrões da Internet. A possibilidade de geração de

aplicações de software, integrando serviços de domínios heterogêneos, de uma forma mais

con�ável, faz valer a pena enfrentar os desa�os inerentes a esse paradigma. Para garantir

a qualidade na construção desses serviços, algumas pesquisas se esforçam para propor

a adoção de técnicas de veri�cação para identi�car e corrigir os erros. Nesse contexto,

manipulação de exceção é um poderoso mecanismo para incrementar a qualidade no uso

de serviços web. Diversos trabalhos de pesquisa são concentrados em mecanismos para

propagação de exceção no uso de serviços web, implementados em muitas linguagens e fra-

meworks. No entanto, são poucos os trabalhos encontrados que avaliam esses mecanismos

no que diz respeito ao framework .NET. A principal contribuição desse trabalho é avaliar

as exceções propagadas e propor mecanismos para o tratamento dessas exceções no uso

de serviços web em aplicações desenvolvidas com o framework .NET. Nessa direção, esse

trabalho: (i) estende um estudo anterior, mostrando a necessidade de se propor uma so-

lução para a propagação de exceção no uso de serviços web para aplicações desenvolvidas

em .NET, e (ii) apresenta uma solução, tomando como base um modelo obtido a partir

dos resultados encontrados em (i), implementando e avaliando a solução em dois estudos

de caso.

Palavras-chave: Serviços Web, Injeção de defeito, Propagação de Exceção.

An Approach to Evaluating and Handling ofPropagated Exceptions in .NET Web Services

Author: José Alex Medeiros de Lima

Supervisor: PhD. Nélio Alessandro Azevedo Cacho

Abstract

High dependability, availability and fault-tolerance are open problems in Service-Oriented

Architecture (SOA). Web services consist of an SOA architecture implementation based

on Internet standards. The possibility of generating software applications by integrating

services from heterogeneous domains, in a reliable way, makes worthwhile to face the

challenges inherent to this paradigm. In order to ensure quality in service, some research

e�orts proposes the adoption of veri�cation techniques to identify and correct errors. In

this context, exception handling is a powerful mechanism to increase the quality in web

services. Several research works are concerned with mechanisms for exception propagation

in web services, implemented in many languages and frameworks. However, there are very

few studies that evaluate these mechanisms to the framework .NET. The main contri-

bution of this work is to evaluate propagated exceptions and to propose mechanisms for

the handling of these exceptions in web services to applications developed with the .NET

framework. In this direction, this work: (i) extends a previous study, showing the need to

propose a solution to the exception propagation in web services to applications developed

in .NET, and (ii) show a solution, based in model obtained from the results found in (i),

implementing and evaluating the solution in two case studies.

Keywords : Web Services, Fault Injection, Exception Propagation.

Lista de �guras

1 Sequência entre defeito, erro e falha . . . . . . . . . . . . . . . . . . . . p. 20

2 Exemplo de ligação estática e dinâmica de tratadores de exceção . . . . p. 21

3 Abordagem para a captura da exceção propagada para análise . . . . . p. 22

4 Abordagem de (GORBENKO et al., 2008) . . . . . . . . . . . . . . . . . . p. 23

5 Arquitetura WCF em execução adaptada de (LOWY, 2007) . . . . . . . p. 28

6 Diagrama de sequência da abordagem . . . . . . . . . . . . . . . . . . . p. 31

7 Código para capturar as falhas Network connection break-o�, Domain

Name System Down, Remote Host Unavailable e Application Server Down p. 33

8 Exemplo de log gerado para a falha Network connection break-o� . . . p. 34

9 Código para capturar a falha Suspension Of WS During Transaction . p. 35

10 Código para capturar a exceção da falha System run-time error . . . . p. 36

11 Código para capturar a exceção da falha Application run-time error . . p. 37

12 Código para capturar a exceção da falha Error Causing user-de�ned ex-

ception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 38

13 Código do método getMulThrow do serviço web . . . . . . . . . . . . . p. 38

14 Código para capturar a exceção das falhas Error in target name space,

Error in service operations name, Output Parameter Type Mismatch,

Input Parameter Type Mismatch, Error In Name Of Input Parameter,

Mismatching Of Number Of Input Params, Error in Web Service Name,

Error in Service Port Name e WS style mismatching (Rpc or Doc) . . p. 40

15 Grá�co quantitativo das mensagens propagadas . . . . . . . . . . . . . p. 42

16 Trecho da stack trace da falha Domain Name System Down, simulada

para a plataforma .NET . . . . . . . . . . . . . . . . . . . . . . . . . . p. 45

17 Diagrama de atividades para a identi�cação das exceções propagadas . p. 50

18 Diagrama de classe da DLL ModuloTratador . . . . . . . . . . . . . . . p. 53

19 Exemplo estrutura do arquivo XMLPROPAGACOES.xml . . . . . . . . p. 57

20 Exemplo grupo XML ENDPOINTNOTFOUNDEXCEPTION . . . . . p. 57

21 Exemplo grupo XML FAULTEXCEPTION . . . . . . . . . . . . . . . . p. 57

22 Exemplo grupo XML COMMUNICATIONEXCEPTION . . . . . . . . p. 58

23 Exemplo grupo XML INVALIDOPERATIONEXCEPTION . . . . . . . p. 58

24 Aspecto AspectoTratador . . . . . . . . . . . . . . . . . . . . . . . . . . p. 59

25 Anotação AspectoTratador . . . . . . . . . . . . . . . . . . . . . . . . . p. 60

26 Modelo conceitual da GNRE on-line (SEFAZ/PE, 2010) . . . . . . . . . p. 63

27 Modelo conceitual do compartilhamento da NF-e entre a SET/RN e o

DETRAN/RN (ENCAT, 2008) . . . . . . . . . . . . . . . . . . . . . . . p. 69

28 Retorno da tela Consulta NF-e . . . . . . . . . . . . . . . . . . . . . . p. 75

Lista de tabelas

1 Falhas de (GORBENKO et al., 2008) . . . . . . . . . . . . . . . . . . . . p. 26

2 Informações de alto nível levantadas pelas falhas simuladas . . . . . . . p. 41

3 Análise de desempenho do mecanismo de propagação de exceções . . . p. 46

4 Comparação dos resultados obtidos neste trabalho e (GORBENKO et al.,

2008) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 48

5 Análise do comportamento no uso do EHWSNET com o serviço web da

GNRE on-line . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 65

6 Análise do Delay(ms) no uso do EHWSNET com o serviço web da GNRE

on-line . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 66

7 Modularidade do EHWSNET com a aplicação web da GNRE on-line . p. 67

8 Análise do comportamento do uso do EHWSNET com o serviço web do

compartilhamento NF-e/DETRAN . . . . . . . . . . . . . . . . . . . . p. 71

9 Análise do Delay(ms) no uso do EHWSNET com o serviço web do com-

partilhamento NF-e/DETRAN . . . . . . . . . . . . . . . . . . . . . . p. 72

10 Modularidade do EHWSNET com a aplicação web do compartilhamento

de NF-e com o DETRAN/RN . . . . . . . . . . . . . . . . . . . . . . . p. 73

11 Comparação entre os trabalhos relacionados . . . . . . . . . . . . . . . p. 78

Lista de abreviaturas e siglas

SOA � Service-Oriented Architecture

HTTP � Hiper Text Transfer Protocol

SOAP � Simple Object Access Protocol

WSDL � Web Service Description Language

UDDI � Universal Description, Discovery and Integration

JAX-RPC � Java API for XML-based RPC

IBM � International Business Machines

DNS � Domain Name System

IP � Internet Protocol

RPC � Remote Procedure Call

CLR � Common Language Runtime

WCF � Windows Communication Foundation

IIS � Internet Information Services

XML � eXtensible Markup Language

HTTPS � Hiper Text Transfer Protocol Secure

TCP � Transmission Control Protocol

IDE � Integrated Development Environment

EHWSNET � Exception Handling in .NET Web Services

DLL � Dynamic Link Library

LOC � Lines Of Code

API � Application Programming Interface

LAN � Local Area Network

AOP � Aspect-oriented Programming

GNRE � Guia Nacional de Recolhimento de Tributos Estaduais

NF-e � Nota Fiscal eletrônica

DETRAN/RN � Departamento Estadual de Trânsito do Rio Grande do Norte

SET/RN � Secretaria de Estado da Tributação do Estado do Rio Grande do Norte

CDC � Concern Di�usion over Components

CDO � Concern Di�usion over Operations

CDLOC � Concern Di�usion over LOC

SEFAZ/PE � Secretaria da Fazenda do Estado de Pernambuco

UF � Unidade da Federação

RN � Rio Grande do Norte

LOC � Lines Of Code

SCA � Service Component Architecture

WS-BPEL � Web Service - Business Process Execution Language

REST � Representational State Transfer

Sumário

1 Introdução p. 16

1.1 Problema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 17

1.2 Objetivos e Metodologia . . . . . . . . . . . . . . . . . . . . . . . . . . p. 18

1.3 Organização do texto . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 18

2 Fundamentos p. 19

2.1 Defeito, Erro e Falha . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 19

2.2 Propagação de Exceção . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 20

2.3 Abordagem para a Propagação de Exceção no Uso de Serviços Web . . p. 22

2.4 Serviços Web em .NET . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 27

3 Avaliação da propagação de exceção em .NET p. 30

3.1 De�nição . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 30

3.2 Planejamento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 30

3.2.1 Processo de pesquisa . . . . . . . . . . . . . . . . . . . . . . . . p. 30

3.2.2 Formulação de questões . . . . . . . . . . . . . . . . . . . . . . p. 31

3.2.3 Projeto do estudo realizado . . . . . . . . . . . . . . . . . . . . p. 31

3.3 Execução através da Injeção de defeito . . . . . . . . . . . . . . . . . . p. 32

3.4 Métricas Adotadas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 40

3.5 Resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 41

3.5.1 Análise de Correspondência . . . . . . . . . . . . . . . . . . . . p. 42

3.5.1.1 Falhas compartilhando a mesma exceção e a mesma

mensagem . . . . . . . . . . . . . . . . . . . . . . . . . p. 42

3.5.1.2 Falhas com informações exatas acerca da falha ocorrida p. 43

3.5.1.3 Falhas que não geraram exceções no sistema . . . . . . p. 43

3.5.1.4 Falha com retorno diferente de tipo da exceção . . . . p. 44

3.5.2 Análise de Desempenho . . . . . . . . . . . . . . . . . . . . . . p. 44

3.5.3 Comparando com soluções em Java . . . . . . . . . . . . . . . . p. 47

4 EHWSNET: Uma solução para Tratamento de Exceções no uso de

Serviços Web na plataforma .NET p. 49

4.1 Abordagem para a identi�cação das exceções propagadas . . . . . . . . p. 49

4.2 DLL ModuloTratador . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 52

4.2.1 Tratamento para o tipo EndpointNotFoundException . . . . . . p. 53

4.2.1.1 Função InternetGetConnectedState . . . . . . . . . . . p. 53

4.2.1.2 Método TesteDNSeConectividadeHost . . . . . . . . . p. 54

4.2.2 Tratamento para o tipo FaultException . . . . . . . . . . . . . . p. 54

4.2.3 Tratamento para o tipo CommunicationException . . . . . . . . p. 55

4.2.4 Tratamento para o tipo InvalidOperationException . . . . . . . p. 55

4.2.5 Método AchouMensagem . . . . . . . . . . . . . . . . . . . . . . p. 55

4.2.5.1 Arquivo XMLPROPAGACOES.xml . . . . . . . . . . p. 56

4.2.5.2 Método CarregarFalhasMensagens . . . . . . . . . . . p. 58

4.3 Utilizando AOP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 58

5 Avaliação da solução EHWSNET p. 61

5.1 Objetivo da avaliação . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 61

5.2 Con�guração do ambiente de avaliação . . . . . . . . . . . . . . . . . . p. 62

5.3 Uso do EHWSNET com o serviço web da GNRE on-line . . . . . . . . p. 62

5.3.1 Análise do comportamento . . . . . . . . . . . . . . . . . . . . . p. 64

5.3.2 Modularidade . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 67

5.4 Uso do EHWSNET com o serviço web do Compartilhamento de NF-e

com o DETRAN/RN . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 68

5.4.1 Análise do comportamento . . . . . . . . . . . . . . . . . . . . . p. 70

5.4.2 Modularidade . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 72

5.5 Conclusões . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 73

6 Trabalhos Relacionados p. 76

7 Conclusão p. 79

7.1 Limitações . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 80

7.2 Trabalhos Futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 80

Referências p. 81

17

1 Introdução

A Arquitetura Orientada a Serviços (SOA - do inglês: Service-Oriented Architec-

ture) consiste em um estilo arquitetural que utiliza serviços como elementos básicos no

desenvolvimento de aplicações. Essas aplicações são caracterizadas por serem fracamente

acopladas e integrarem ambientes heterogêneos (MARKS; BELL, 2006), (PAPAZOGLOU et

al., 2008).

Serviços web consistem em uma implementação da arquitetura SOA baseada em pa-

drões da Internet (PAPAZOGLOU et al., 2008), tais como: (i) o protocolo de comunica-

ção HTTP (Hiper Text Transfer Protocol); (ii) o protocolo SOAP (Simple Object Access

Protocol), utilizado para troca de informações estruturadas de forma descentralizada e

distribuída; (iii) a linguagem WSDL (Web Service Description Language), utilizada para

descrever serviços, de�nir interfaces e mecanismos de interação; e (iv) o serviço de re-

gistro UDDI (Universal Description, Discovery and Integration), usado para descrição,

descoberta e integração de serviços.

Apesar de trazer vários benefícios ao desenvolvimento de software, este paradigma

apresenta desa�os e riscos ao desenvolvimento de aplicações robustas. Um sistema de

software robusto precisa reagir à propagação de erros em seus módulos sem comprometer

o sistema (LEE; ANDERSON, 1990).

Desenvolvedores de sistemas robustos frequentemente se referem às falhas como exce-

ções porque falhas raramente se manifestam durante a atividade normal do sistema (GO-

ODENOUGH, 1975). Em situações de defeito, que é o problema que pode ter manifestado

a falha, que é de percepção externa, ou seja, pelos usuários do sistema, um componente

gera exceções que modelam a condição do defeito e o sistema deve realizar o tratamento

daquelas exceções. Desta forma, tratamento de exceções é a capacidade que um software

possui de reagir apropriadamente diante da ocorrência de exceções, continuando ou inter-

rompendo sua execução, a �m de preservar a integridade do estado do sistema (GARCIA

et al., 2001).

18

O tratamento de exceções é um dos mecanismos mais utilizados para implementar

sistemas robustos (GORBENKO et al., 2008). Ele está embutido na maioria das linguagens

de programação, tais como Java, C# e C++. Essas linguagens oferecem abstrações para

encapsular as condições excepcionais e construções próprias para lidar com elas durante

a execução do programa, tanto na detecção, quanto no tratamento destas condições.

O desenvolvimento de aplicações robustas baseadas em serviços web pode se bene�-

ciar dos mecanismos de tratamento de exceções (GORBENKO et al., 2008). Neste contexto,

exceções podem ser lançadas por quaisquer dos serviços que compõem uma aplicação.

De acordo com (GORBENKO et al., 2008), conhecer as causas exatas e os elementos si-

nalizadores das exceções geradas durante a execução de serviços web permite que os

desenvolvedores apliquem as técnicas adequadas de tratamento de exceções.

Porém, para que os reais benefícios da adoção dos mecanismos de tratamento de exce-

ções possam ser alcançados no contexto de serviços web, estudos precisam ser realizados

para responder às seguintes questões (GORBENKO et al., 2008): Como as exceções estão

�uindo nos serviços web? Elas realmente podem contribuir para melhorar a robustez dos

sistemas?

1.1 Problema

A maioria das exceções propagadas no contexto de serviços web não identi�cam os

defeitos, e as que identi�cam, não noti�cam a causa raiz do defeito (GORBENKO et al.,

2008). Conhecer as características da propagação da exceção de cada defeito possibilita

melhorar o tratamento de falhas no uso de serviços web (GORBENKO et al., 2008).

Na busca por trabalhos no estado da arte com o objetivo de analisar esses problemas,

tendo como foco o comportamento e propagação das exceções lançadas e o seu desempe-

nho, trabalhos como os de (GORBENKO et al., 2008), (KOPP; LEYMANN; WUTKE, 2010) e

(LOOKER; MUNRO; XU, 2004) foram encontrados, mas nenhum deles analisou as aplica-

ções .NET quando essas exceções são geradas. A plataforma .NET é utilizada por 20%

dos sites web conhecidos, principalmente em sites de negócio, compras e tecnologia, o que

corresponde a 8.036.491 sites. Deste total, 1.485.430 sites estão entre os mais visitados na

internet (WITH, 2013) e (W3TECHS, 2013).

Neste contexto, o trabalho apresentado estende o estudo descrito em (GORBENKO et

al., 2008). No estudo de (GORBENKO et al., 2008), foram analisados os mecanismos de

propagação de exceção de dois toolkits de desenvolvimento de serviços web em Java para

19

entender suas implicações no desempenho de aplicações SOA. O presente trabalho estende

o estudo para uma análise das exceções propagadas no uso de serviços web na plataforma

.NET da Microsoft e propõe uma possível solução para melhorá-las.

1.2 Objetivos e Metodologia

O objetivo principal deste estudo é analisar as exceções propagadas no uso de servi-

ços web na plataforma .NET e propor uma solução que resolva o problema descrito na

seção anterior, que é a identi�cação do defeito, determinando qual falha ocorreu, dando

assim subsídio para o programador melhorar a robustez em seus sistemas ou realizar a

manutenção da falha ocorrida de forma mais ágil e objetiva.

Como metodologia, injeções de defeitos (HOSSAIN, 2006) foram utilizadas para simular

as falhas e analisar o comportamento do serviço web e da aplicação cliente no que diz

respeito aos mecanismos de propagação de exceções. Além disso, as seguintes atividades

também foram realizadas:

• Analisar o estado da arte para as exceções propagadas no uso de serviços web na

plataforma .NET;

• Propor solução para o tratamento de exceções propagadas no uso de serviços web

na plataforma .NET;

• Analisar a solução proposta em estudos de caso com soluções reais.

1.3 Organização do texto

O restante deste trabalho está organizado da seguinte forma: no Capítulo 2 são apre-

sentados alguns fundamentos básicos para o entendimento deste trabalho; o Capítulo 3

apresenta a avaliação da propagação de exceção; o Capítulo 4 apresenta a solução pro-

posta; o Capítulo 5 apresenta a avaliação da solução proposta; os trabalhos relacionados

estão no Capítulo 6 e o Capítulo 7 apresenta a conclusão.

20

2 Fundamentos

Esse capítulo traz uma discussão dos assuntos teóricos abordados nessa dissertação.

São expostos fundamentos e estudos sobre: defeito, erro e falha, propagação de exceção

e o artigo que serviu como base para a elaboração da abordagem para avaliá-la, além de

serviços web em .NET.

2.1 Defeito, Erro e Falha

Um sistema de software consiste de um conjunto de componentes que interagem de

acordo com o especi�cado em um projeto de software, a �m de atender as demandas do

ambiente (LEE; ANDERSON, 1990). O projeto de�ne como os componentes irão interagir e

estabelece as conexões entre os componentes e o ambiente. Para ser con�ável, um sistema

de software precisa entregar o serviço esperado mesmo na presença de condições anormais.

Um serviço é considerado entregue quando ele implementa corretamente as funções do

sistema para o qual foi desenvolvido (AVIZIENIS et al., 2004). Para tal, ele recebe requisições

e produz respostas que devem estar de acordo com as especi�cações �cando assim em um

estado consistente.

Quando por algum motivo esse estado sofre uma alteração que o torne inconsistente,

é dito que ocorreu um erro (LEE; ANDERSON, 1990), (AVIZIENIS et al., 2004). Uma falha

(LEE; ANDERSON, 1990), (AVIZIENIS et al., 2004) é a manifestação de um ou mais erros

e é de percepção externa, ou seja, pelos usuários do sistema. O problema que pode ter

originado o erro, que foi manifestado através de uma falha é denominado defeito, que pode

ter origem interna ou externa aos limites do software (AVIZIENIS et al., 2004), ou seja,

problemas internos no código-fonte ou através de interações errôneas, falhas de hardware,

etc. A Figura 1 exibe a sequência da ocorrência do defeito até a manifestação da falha.

21

Figura 1: Sequência entre defeito, erro e falha

2.2 Propagação de Exceção

Estratégias para ligação de tratadores e propagação de exceção estão fortemente rela-

cionadas ao modo como exceções são propagadas ao longo da cadeia de chamadas. Dentre

as estratégias para as ligações tem-se a ligação estática de tratador, que depende da propa-

gação explícita e a ligação dinâmica, que exige propagação automática (LEE; ANDERSON,

1990).

Reuso e variabilidade de tratadores inevitavelmente requerem certo nível de dina-

mismo do mecanismo de ligação do tratador. Normalmente, tratadores são reutilizados

pela captura de exceções relacionadas à execução de métodos. Se um tratador é esta-

ticamente ligado, ele só capturará exceções propagadas por métodos a menos que seja

executada uma propagação explícita (LEE; ANDERSON, 1990). Em contraste a essa abor-

dagem, a abordagem dinâmica suporta reuso de código excepcional por meio da de�nição

de tratadores simples que podem tratar exceções propagadas pela execução de métodos a

partir da propagação automática (LEE; ANDERSON, 1990).

A Figura 2 mostra nas linhas 8 e 21 a de�nição de um tratador que utiliza a abordagem

de ligação dinâmica para capturar todas as exceções lançadas por todos os mecanismos

de persistência. Essa estratégia permite que um programador reutilize código através da

descrição sucinta de um tratador para um conjunto de exceções relacionadas. Também

na Figura 2, nas linhas 43 e 46, são mostrados casos nos quais duas exceções são espe-

ci�camente tratadas: RecordStoreMechanismException e FileSystemMechanismException.

Como consequência, o tratamento da exceção capturada só será realizado para os tipos in-

formados, característica da ligação estática. Para garantir o tratamento de novas exceções,

novos tipos terão que ser introduzidos, sobrecarregando os tipos já existentes.

22

Figura 2: Exemplo de ligação estática e dinâmica de tratadores de exceção

Adicionalmente, abordagens dinâmicas podem capturar informações em tempo de exe-

cução para adaptar o comportamento do tratador, utilizando o tipo da exceção capturada

para decidir qual operação será realizada (LEE; ANDERSON, 1990). No presente trabalho

a abordagem utilizada foi a dinâmica, onde o cliente invocou um método do serviço web

através da rede e capturou a exceção propagada para análise. A Figura 3 exempli�ca a

abordagem utilizada.

23

Figura 3: Abordagem para a captura da exceção propagada para análise

2.3 Abordagem para a Propagação de Exceção no Uso

de Serviços Web

O artigo de (GORBENKO et al., 2008) foi utilizado como base para a elaboração da

abordagem para a avaliação da propagação de exceção no uso de serviços web. Nele, é

apresentada uma experiência prática com os resultados encontrados em defeitos injetados

no uso de serviços web. Os experimentos foram restritos às manipulações de exceções

especí�cas fornecidas por dois kits de desenvolvimento em Java: o Sun Microsystems

JAX-RPC (Java API for XML-based RPC) e o IBM (International Business Machines)

WebSphere Software Developer Kit for Web Services.

O foco principal do trabalho de (GORBENKO et al., 2008) foi a análise da propaga-

ção de exceção e o desempenho como fatores principais que afetam a tolerância à falha

(em particular, tratamento de erros e diagnóstico de falhas) no uso de serviços web. A

abordagem de (GORBENKO et al., 2008) está representada pela Figura 4.

24

Figura 4: Abordagem de (GORBENKO et al., 2008)

Para conduzir o experimento, (GORBENKO et al., 2008) primeiro implementou uma

classe Java chamada WSCalc, com uma simples operação aritmética envolvendo dois in-

teiros, convertendo o resultado em uma string (passo 1 da Figura 4). Foram implementados

dois serviços web, um para cada kit de desenvolvimento analisado, com a classe Java im-

plementada e foram hospedados em dois servidores de aplicação, um do IBM WebSphere

e o outro rodando o serviço web desenvolvido através do kit de desenvolvimento da SUN

(passo 2 da Figura 4). Foram injetadas e analisadas falhas especí�cas (passos 3 e 4 da

Figura 4). Os resultados do experimento foram analisados a partir da relação entre a falha

simulada e a exceção propagada capturada, de forma comparativa (passo 5 da Figura 4),

e de acordo com o seu desempenho (passo 6 da Figura 4).

As falhas experimentadas no trabalho de (GORBENKO et al., 2008) foram divididas em

três categorias: (i) falhas de rede e sistemas remotos que foram simuladas manualmente;

(ii) falhas do serviço web que foram simuladas por injeções de defeitos no lado do serviço

25

e (iii) falhas do lado cliente que foram simuladas no momento da invocação ao serviço

web com injeções de defeitos em tempo de desenvolvimento alterando o código fonte do

cliente para injetar os defeitos no sistema.

As falhas de rede colocadas por (GORBENKO et al., 2008) foram:

• Network Connection break-o� : Alguns fatores podem causar esse tipo de falha, como

problemas físicos (intempéries, quebra de equipamentos, problemas no cabeamento,

etc.), ou fatores como queda de sinal, por exemplo. Falha simulada por (GORBENKO

et al., 2008) no lado do cliente.

• Domain Name System Down: É a inoperância do protocolo de gerenciamento de

nomes e domínios (DNS ). Com isso, a comunicação �ca comprometida pela impos-

sibilidade de tradução de endereços nominais em endereços IP (Internet Protocol)s.

• Remote host unavailable: A comunicação não é concretizada pela indisponibilidade

do host no qual o serviço está hospedado, estando ele o�-line ou inacessível devido

à falhas na rede.

• Application server is down: Ocorre pela queda do servidor de aplicação, seja por

motivos físicos, seja em razão do alto número de solicitações de serviços, ou por

outros motivos, como o desligamento intencional do servidor, por exemplo.

• Loss of request/response packet : Ocorre quando há perda de pacotes durante a co-

municação devido a congestionamento da rede.

As falhas do serviço web colocadas por (GORBENKO et al., 2008) foram:

• Suspension of WS during transaction: Ocorre quando há interrupção no provimento

do serviço, durante uma transação entre o consumidor e o serviço.

• System run-time error : São falhas que ocorrem em tempo de execução, em nível

de sistema, provocadas pelo código de execução do serviço web. Por exemplo, o

estouro de pilha de execução, o acesso a posições inexistentes de vetores, ou falhas

aritméticas de uma determinada operação do serviço.

• Application run-time error ("Operand type mismatch"): São falhas geradas por có-

digo mal implementado, por exemplo, o uso de parâmetros considerados ilegais ou

impróprios em determinado contexto, não coincidindo o parâmetro enviado e o es-

perado por uma função ou método.

26

• Error Causing user-de�ned exception: Exceção implementada pelo serviço, esten-

dendo um tipo de exceção, lançada por um método do serviço.

Por último, as falhas do lado cliente colocadas por (GORBENKO et al., 2008) foram:

• Error in target namespace: Falha causada pela con�guração errada do namespace

do serviço requisitado.

• Error in service operations name: Chamada de um método inexistente do serviço

web.

• Error in web service name: É a con�guração errada do nome do elemento service

name do WSDL.

• Error in service port name: É a con�guração errada do nome do elemento port name

do WSDL.

• Output parameter type mismatch: Falha causada pela má con�guração do parâmetro

de retorno do serviço.

• Input parameter type mismatch: Falha causada pela má con�guração do tipo de

parâmetro de entrada do serviço.

• Error in name of input parameter : Falha causada pela má con�guração dos nomes

dos parâmetros de entrada do serviço requisitado.

• Mismatching of number of input params : Falha ocasionada pelo envio de uma quan-

tidade incorreta de parâmetros de entrada.

• WS style mismatching : Falha no estilo do serviço web. Dá-se pela má con�guração

na ligação, trocando de document para RPC (Remote Procedure Call), ou vice-versa.

A Tabela 1 resume as falhas de (GORBENKO et al., 2008) organizando-as por categoria.

27

Tabela 1: Falhas de (GORBENKO et al., 2008)

No Falha Categoria

1 Network connection break-o� Rede

2 Domain Name System is down Rede

3 Loss of request/response packet Rede

4 Remote host unavailable Rede

5 Application Server is down Rede

6 Suspension of WS during transaction Serviço web

7 System run-time error Serviço web

8 Application run-time error Serviço web

9 Error causing user-de�ned exception Serviço web

10 Error in Target Name Space Cliente

11 Error in Web Service name Cliente

12 Error in service port name Cliente

13 Error in service operations name Cliente

14 Output parameter type mismatch Cliente

15 Input parameter type mismatch Cliente

16 Error in name of input parameter Cliente

17 Mismatching of number of input params Cliente

18 WS style mismatching (Rpc or Doc) Cliente

Os resultados do experimento de (GORBENKO et al., 2008) foram analisados a partir

da relação entre a falha simulada e a exceção propagada capturada no topo da sua stack

trace no lado cliente.

A relação entre a falha simulada e a exceção propagada foi chamada de Análise de

Correspondência, analisada através das métricas tipo de exceção gerada e mensagem da

exceção retornada. A análise das informações obtidas a partir da stack trace, que contém o

número de métodos percorridos pela exceção propagada até ela ser capturada pelo catch na

aplicação cliente, foi chamada de Análise de Desempenho, analisada através das métricas

número de métodos percorridos pela exceção propagada até ela ser capturada pelo catch na

aplicação cliente e tempo contabilizado da chamada ao serviço até o momento da captura

da exceção. Para (GORBENKO et al., 2008), a Análise de Desempenho pode ajudar na

identi�cação da origem da exceção. Alguns resultados encontrados por (GORBENKO et al.,

28

2008) serão apresentados na seção 3.5.3.

2.4 Serviços Web em .NET

A plataforma .NET tem a capacidade de executar diversas linguagens de programação,

integrando-as como se fossem apenas uma. Através de um ambiente de execução, chamado

CLR (Common Language Runtime), a plataforma .NET agrupa e gerencia todas essas

linguagens, facilitando a manutenção e o desenvolvimento ao oferecer diversos serviços

comuns às aplicações (LOWY, 2007).

Na plataforma .NET, a partir do seu framework 3.0, os serviços web começaram a

ser desenvolvidos e consumidos utilizando a arquitetura WCF (Windows Communication

Foundation). Esta solução da Microsoft para o desenvolvimento de aplicações que se

intercomunicam (LOWY, 2007) foi utilizada para o desenvolvimento do presente trabalho.

Através do WCF, são enviados dados como mensagens assíncronas de um endpoint de

serviço para outro (MSDN, 2014). Um endpoint de serviço pode ser parte de um serviço

continuamente disponível hospedado pelo IIS (Internet Information Services), servidor

de aplicação fornecido pela Microsoft responsável por gerenciar serviços e aplicações web,

principalmente .NET, ou pode ser um serviço hospedado em um aplicativo.

Um endpoint pode também ser um cliente de um serviço que solicita dados a partir

de um endpoint de serviço. As mensagens podem ser tão simples como um único caractere

ou palavra enviada como XML (eXtensible Markup Language), ou tão complexo como um

�uxo de dados binários (MSDN, 2014).

O padrão mais comum das trocas de mensagem é o request/response, onde um endpoint

solicita dados de um segundo endpoint e esse o responde. Há outros padrões, tais como

uma mensagem de mão única, em que um único endpoint envia uma mensagem sem

expectativa de uma resposta (MSDN, 2014).

Embora a criação e a utilização de serviços web fosse possível antes da existência

do WCF, o WCF torna o desenvolvimento de endpoints mais fácil. Em resumo, o WCF

é projetado para oferecer uma abordagem gerenciável para a criação de serviços web e

clientes de serviços web (MSDN, 2014).

Essencialmente, o WCF descreve um �uxo de execução conforme descrito na Figura 5.

Tal �uxo é formado por um componente chamado distribuidor (no contexto do servidor)

e um componente chamado de proxy (no contexto cliente) que são os responsáveis por

29

fazerem a tradução das mensagens dos objetos do WCF para os demais métodos do

framework .NET. A Figura 5 ilustra como as mensagens seguem uma sequencia bem

de�nida de etapas para realizar este processo (LOWY, 2007).

Tanto no distribuidor, como no proxy, são fornecidos pontos de extensibilidade onde

alguma funcionalidade pode ser adicionada. Esses pontos de extensibilidade podem ser

utilizados para implementar uma grande variedade de comportamentos personalizados

(LOWY, 2007), como por exemplo: inclusão de mensagens ou parâmetros de validação,

registro e transformações de mensagens, serialização personalizada, de�nição de formatos

de desserialização, de�nição de cache de saída, agrupamento de objetos, tratamentos de

falhas e de autorização.

Figura 5: Arquitetura WCF em execução adaptada de (LOWY, 2007)

Na camada de mensagem as mensagens são enviadas entre os endpoints com as de�-

nições de todas as informações necessárias para a troca de mensagens. Um serviço expõe

um ou mais endpoints para a aplicação e o cliente gera um endpoint que é compatível

com um dos endpoints do serviço (LOWY, 2007).

O endpoint determina o padrão em que as mensagens serão enviadas, como elas serão

enviadas e como elas serão recebidas. O serviço expõe essa informação como metadados,

onde os clientes podem processá-la para gerar clientes WCF e pilhas de comunicação

adequadas.

Na camada de transporte, os principais meios de transporte utilizados são HTTP,

30

HTTPS (Hiper Text Transfer Protocol Secure), TCP (Transmission Control Protocol)

e named pipes. Nela, o meio de transporte é escolhido e con�gurado (LOWY, 2007). O

protocolo de transporte será requerido na camada de comunicação, onde as mensagens

serão enviadas. Outro elemento necessário na pilha de comunicação é a codi�cação que

especi�ca como a mensagem estará formatada (LOWY, 2007).

31

3 Avaliação da propagação de

exceção em .NET

Nesse capítulo será apresentada a avaliação da propagação de exceção no uso de

serviços web em .NET, que servirá como base para se propor uma solução que determine

a falha ocorrida no uso desses serviços. Nele, será descrito como foi realizada a abordagem

para a avaliação e como as exceções foram propagadas, apresentando e analisando os

resultados encontrados.

3.1 De�nição

Utilizando a linguagem C#, foi desenvolvido um serviço web similar ao WSCalc apre-

sentado em (GORBENKO et al., 2008). O objetivo foi analisar os mecanismos de propagação

do �uxo de exceções em aplicações que utilizam serviços web e que foram desenvolvidos,

cliente e serviço, com o framework .NET, como uma extensão do estudo descrito em

(GORBENKO et al., 2008), que trabalhou com dois kits de desenvolvimento em Java: o Sun

Microsystems JAX-RPC e o IBM WebSphere Software Developer Kit for Web Services.

Os resultados encontrados foram analisados a partir da relação entre a falha simulada e

a exceção propagada capturada no topo da sua stack trace no lado cliente.

3.2 Planejamento

3.2.1 Processo de pesquisa

A partir do endereço e porta gerados para acesso ao serviço web, foram realizadas

manualmente injeções de defeitos para as falhas de rede, foram injetados defeitos no serviço

web para simular as falhas no lado do serviço durante a sua execução e foram também

injetados defeitos em tempo de desenvolvimento no código fonte do cliente, alterando o seu

código para simular as falhas no lado do cliente, coletando assim as métricas necessárias

32

para o estudo.

Na Figura 6 é mostrado o diagrama de sequência da abordagem. O cliente .NET,

desenvolvido na IDE (Integrated Development Environment) Visual Studio 2010 para

.NET, invoca o método do serviço web e captura as exceções propagadas para análise. O

proxy da arquitetura WCF é o responsável pela intercomunicação entre o cliente .NET

e o serviço web. No lado do serviço se tem o distribuidor da arquitetura WCF que é o

responsável por receber a requisição do proxy e garantir a intercomunicação com o serviço

web. O serviço web .NET, também desenvolvido na IDE Visual Studio 2010 e hospedado

no servidor web IIS, possui a classe .NETWSCalc que é usada para as injeções dos defeitos

no lado do serviço.

Figura 6: Diagrama de sequência da abordagem

3.2.2 Formulação de questões

Para que os reais benefícios possam ser avaliados, é tido como objetivo responder as

seguintes perguntas: Como as falhas são reportadas? Como as exceções estão �uindo nos

serviços web? Elas realmente podem contribuir para uma melhor robustez dos sistemas?

3.2.3 Projeto do estudo realizado

Para atingir o objetivo e responder os questionamentos, injeção de defeitos foram

utilizados para simular as falhas propostas por (GORBENKO et al., 2008). Os resultados

33

retornados foram utilizados para analisar o comportamento do serviço web e da aplicação

cliente no que diz respeito aos mecanismos de propagação de exceções.

3.3 Execução através da Injeção de defeito

Injeção de defeito é uma técnica utilizada para avaliar processo de validação de con-

�abilidade e de grande importância no desenvolvimento de software robustos (HOSSAIN,

2006). Determinadas falhas podem ser a causa para ocorrências de outras. Para a utiliza-

ção dessa técnica é importante determinar os locais onde os defeitos podem ser injetados.

Algumas falhas podem ser simuladas com a queda de serviços. Por exemplo, a falha

Network Connection break-o�, cujo o defeito injetado foi a perda da conexão de rede,

foi simulada manualmente com o desligamento da conexão de rede do cliente durante a

ligação.

Na simulação de Domain Name System Down, cujo o defeito injetado foi a não reso-

lução do nome de um domínio, foi de�nido manualmente um endereço de serviço de DNS

incorreto nas con�gurações do sistema operacional, e a aplicação cliente foi executada

logo depois, ocasionando uma falha na resolução de endereço IP.

Na simulação de Remote host unavailable, cujo o defeito injetado foi a perda de comu-

nicação com o servidor, a comunicação entre os hosts (cliente e servidor) foi interrompida

manualmente com a desconexão do servidor da rede durante a ligação. Seguindo a mesma

linha de raciocínio, é possível simular Application server is down, cujo o defeito injetado

foi a indisponibilidade do IIS, parando manualmente o serviço responsável pela execução

do IIS. Durante a simulação, o serviço do IIS foi desligado no servidor no momento da

invocação ao serviço web pelo cliente.

A falha Loss of request/response packet não foi simulada em virtude da impossibilidade

e da não autorização de provocar congestionamentos na rede onde as simulações estavam

sendo realizadas.

O código utilizado para capturar as exceções propagadas pelas falhas Network con-

nection break-o�, Domain Name System Down, Remote Host Unavailable e Application

Server Down está representado pela Figura 7. O trecho de código responsável por gerar a

falha em tempo de execução é o emReference.getMul(2, 2), linha 114 da Figura 7, quando

o método do serviço web é invocado. Como não será possível estabelecer comunicação com

o serviço, será gerada uma exceção que será capturada pelo catch. Pelo código é possível

34

perceber que é gerado um log, linha 122 da Figura 7, onde a exceção propagada será guar-

dada para uma análise futura contendo o tipo da exceção gerada (método ex.GetType()),

linha 121 da Figura 7, bem como os dados da exceção propagada (objeto ex ). A Figura 8

mostra o log que é gerado.

Figura 7: Código para capturar as falhas Network connection break-o�, Domain Name System

Down, Remote Host Unavailable e Application Server Down

35

Figura 8: Exemplo de log gerado para a falha Network connection break-o�

A falha Suspension Of WS During Transaction, cujo o defeito injetado foi a parada

temporária do IIS, foi simulada por meio da inserção de trechos de códigos que atrasam a

�nalização do serviço, provendo tempo hábil para suspender o IIS manualmente, durante

a execução da requisição. Durante a simulação, foi colocado um sleep de 5 segundos dentro

do método HelloWorld do serviço web e durante esse intervalo o serviço foi suspenso.

O código utilizado para capturar a exceção propagada pela falha Suspension Of WS

During Transaction está representado pela Figura 9. Pelo código é possível perceber que

o trecho de código do bloco try, linhas 328, 329 e 330 da Figura 9, é o responsável por

atrasar a �nalização do serviço e é gerado um log, linha 336 da Figura 9, semelhante ao

da Figura 8, onde a exceção propagada será guardada para uma análise futura contendo

o tipo da exceção gerada (método ex.GetType()), linha 335 da Figura 9, bem como os

dados da exceção propagada (objeto ex ).

36

Figura 9: Código para capturar a falha Suspension Of WS During Transaction

Para simular System run-time error, cujo o defeito injetado foi uma operação aritmé-

tica inválida, foi acrescentada uma operação de divisão dentro do método, e na passagem

de parâmetros para o serviço web foi passado um valor zero para o denominador. Como

divisões por zero não existem, a falha gerada pela execução dessa instrução foi, então,

coletada.

O código utilizado para capturar a exceção propagada pela falha System run-time

error está representado pela Figura 10. Pelo código é possível perceber que o trecho de

código responsável por gerar a falha em tempo de execução é o emReference.getDiv(2,

0), linha 364 da Figura 10, e, como no código da Figura 7, é gerado um log, linha 372

da Figura 10, semelhante ao da Figura 8, onde a exceção propagada será guardada para

uma análise futura contendo o tipo da exceção gerada (método ex.GetType()), linha 371

da Figura 10, bem como os dados da exceção propagada (objeto ex ).

37

Figura 10: Código para capturar a exceção da falha System run-time error

A falha Application run-time error, cujo o defeito injetado foi um mau comporta-

mento da aplicação, foi simulada com a utilização de parâmetros ilegais. Inicialmente foi

publicado um serviço web que recebia parâmetros do tipo String. O código do cliente

foi implementado para invocar tal serviço. Após esse passo, o serviço web foi publicado

novamente, agora recebendo parâmetros do tipo inteiro. Como a aplicação cliente não foi

atualizada para a nova interface, a aplicação cliente invocou o serviço passando parâmetros

com o tipo String.

Isto acarretou em uma exceção, devido à conversão de uma palavra para inteiro.

Apesar dos tipos de parâmetros serem irrelevantes na interface do serviço, do ponto de

vista do protocolo SOAP, que utiliza uma representação de dados essencialmente textual,

o serviço internamente estava esperando um valor do tipo inteiro, por isso a exceção em

questão foi propagada.

O código utilizado para capturar a exceção propagada pela falha Application run-time

error está representado pela Figura 11. Pelo código é possível perceber que o trecho de

código responsável por gerar a falha é o emReference.getMulString("211a", "12er"), linha

114 da Figura 11, e, como no código da Figura 7, é gerado um log, linha 122 da Figura

11, semelhante ao da Figura 8, onde a exceção propagada será guardada para uma análise

futura contendo o tipo da exceção gerada (método ex.GetType()), linha 121 da Figura 11,

bem como os dados da exceção propagada (objeto ex ).

38

Figura 11: Código para capturar a exceção da falha Application run-time error

Na simulação de Error causing user-de�ned exception, cujo o defeito injetado foi uma

exceção criada pelo próprio serviço, um método foi criado no serviço web para lançar uma

exceção implementada pelo próprio serviço.

O código utilizado para capturar a exceção propagada pela falha Error Causing user-

de�ned exception está representado pela Figura 12. Pelo código é possível perceber que o

trecho de código responsável por gerar a falha é o emReference.getMulThrow(2, 2), linha

453 da Figura 12, e, como no código da Figura 7, é gerado um log, linha 461 da Figura

12, semelhante ao da Figura 8, onde a exceção propagada será guardada para uma análise

futura contendo o tipo da exceção gerada (método ex.GetType()), linha 460 da Figura

12, bem como os dados da exceção propagada (objeto ex ). A Figura 13 ilustra o código

do método getMulThrow do serviço web que força a simulação da exceção propagada em

questão.

39

Figura 12: Código para capturar a exceção da falha Error Causing user-de�ned exception

Figura 13: Código do método getMulThrow do serviço web

Em Error in target namespace, cujo o defeito injetado foi o nome incorreto do na-

mespace, foi modi�cada manualmente a classe Reference.cs do .NET, classe de con�gu-

ração que representa o WSDL na aplicação cliente, mudando o parâmetro namespace de

http://tempuri.org/ para http://tempur.org/

Em Error in service operations name, cujo o defeito injetado foi o nome incorreto

do método do serviço, foi mudado manualmente no serviço o nome do método de getMul

para getMultiplicacao, quando o cliente executou foi gerada uma exceção porque o cliente

não encontrou o método especi�cado.

Em Output Parameter Type Mismatch, cujo o defeito injetado foi a alteração do tipo

do parâmetro de saída, também foi modi�cada manualmente a classe Reference.cs, alte-

rando o parâmetro de saída do método getMul de string para inteiro. Semelhante à falha

anterior, em Input Parameter Type Mismatch, cujo o defeito injetado foi a alteração do

40

tipo do parâmentro de entrada, foram alterados manualmente os parâmetros de entrada

do método getMul de inteiro para string.

Para a falha Error In Name Of Input Parameter, cujo o defeito injetado foi o nome in-

correto do parâmetro de entrada, foram modi�cados manualmente na classe Reference.cs

os nomes dos parâmetros de entrada do método getMul. Assim como para a falha Mis-

matching Of Number Of Input Params, a simulação foi feita comentando manualmente

um dos parâmetros de entrada do método getMul.

As simulações das falhas Error in Web Service Name e Error in Service Port Name,

cujo o defeito injetado foi o nome incorreto do contrato, foram realizadas alterando ma-

nualmente o parâmetro name no arquivo app.con�g onde �cam os contratos que o WCF

utiliza para as ligações entre o cliente e o serviço web. Valores foram colocados no parâ-

metro name diferentes dos que estavam especi�cados no WSDL do serviço web.

Por �m, a simulação da falha WS style mismatching (Rpc or Doc), cujo o defeito

injetado foi a alteração do estilo, também foi realizada alterando manualmente a classe

Reference.cs que representa o WSDL na aplicação cliente, forçando que o estilo utilizado

pelo cliente para se comunicar com o serviço web fosse o RPC.

O código utilizado para capturar as exceções propagadas pelas falhas Error in target

name space, Error in service operations name, Output Parameter Type Mismatch, Input

Parameter Type Mismatch, Error In Name Of Input Parameter, Mismatching Of Number

Of Input Params, Error in Web Service Name, Error in Service Port Name e WS style

mismatching (Rpc or Doc) está representado pela Figura 14.

Também como no código da Figura 7, é possível perceber que é gerado um log, linha

122 da Figura 14, semelhante ao da Figura 8, onde a exceção propagada será guardada

para uma análise futura contendo o tipo da exceção gerada (método ex.GetType()), linha

121 da Figura 14, bem como os dados da exceção propagada (objeto ex ).

41

Figura 14: Código para capturar a exceção das falhas Error in target name space, Error in service

operations name, Output Parameter Type Mismatch, Input Parameter Type Mismatch, Error

In Name Of Input Parameter, Mismatching Of Number Of Input Params, Error in Web Service

Name, Error in Service Port Name e WS style mismatching (Rpc or Doc)

3.4 Métricas Adotadas

Baseado em (GORBENKO et al., 2008), foram coletadas quatro métricas: número de

métodos percorridos pela exceção propagada até ela ser capturada pelo catch na aplicação

cliente, o tipo de exceção gerada, a mensagem retornada à aplicação cliente e o tempo

contabilizado da chamada ao serviço até o momento da captura da exceção.

O número de métodos percorridos mostra o tamanho da pilha de chamadas, ou seja,

o número de métodos por onde a exceção passou até chegar ao topo da pilha, até ser

capturada por um bloco catch. Através dessa métrica é possível analisar o tamanho do

caminho percorrido pela exceção até seu destino. O tipo da exceção é sua classe, o tipo

de objeto que será capturado pelo bloco catch na aplicação cliente.

A mensagem de exceção retornada é a mensagem gerada pelo próprio framework,

sendo a exceção um objeto que possui muitos atributos. A mensagem é um dos atributos,

que contém informações acerca da falha ocorrida. Por �m, o tempo gasto fornece uma

noção do tempo necessário para a plataforma identi�car e tratar uma falha.

42

Na simulação das falhas, arquivos de log foram gerados em cada experimento, conforme

já apresentado na Figura 8, contendo: (i) o tipo de exceção gerada; (ii) a mensagem de

exceção retornada; (iii) o estado da pilha com o caminho percorrido; (iv) o tempo de início

e de �m a partir da geração da falha e (v) a descrição do método utilizado para simular

a falha.

3.5 Resultados

A Tabela 2 detalha os tipos de exceção e as mensagens propagadas em cada uma das

falhas testadas.

Tabela 2: Informações de alto nível levantadas pelas falhas simuladasNo Descrição da Falha Tipo da Exceção Mensagem da Exceção

1 Network connection break-

o�

EndpointNotFoundException There was no endpoint listening at

http://10.84.110.32:8081/wscalc.asmx that could accept the mes-

sage. This is often caused by an incorrect address or SOAP action. See

InnerException, if present, for more details.

2 Domain Name System

Down





3 Remote Host Unavailable EndpointNotFoundException There was no endpoint listening at




4 Application Server is

Down





5 Suspension Of WS During

Transaction

CommunicationException An error occurred while receiving the HTTP response to

http://10.84.110.32:8081/wscalc.asmx. This could be due to the

service endpoint binding not using the HTTP protocol. This could

also be due to an HTTP request context being aborted by the server

(possibly due to the services shutting down). See server logs for more

details.

6 System Run-Time Error FaultException Server was unable to process request. �to divide by zero.

7 Application run-time er-

ror ("Operand Type Mis-

match")

FaultException Server was unable to process request. �>Input string was not in a

correct format.

8 Error Causing user de�ned

exception

FaultException Server was unable to process request. �>Exception throwed to test

error 9. Propagation of an user de�ned exception.

9 Error in Target Namespace FaultException Server did not recognize the value of HTTP Header SOAP Ac-

tion:http://tempur.org/getMulThrow.

10 Error in Web Service

Name

- -

11 Error in Service Port

Name

- -

12 Error in service operations

name

FaultException Server did not recognize the value of HTTP Header SOAP Ac-

tion:http://tempuri.org/getMul.

13 Output Parameter type

mismatch

- -

14 Input Parameter Type

Mismatch

- -

15 Error in name of input pa-

rameter

- -

16 Mismatching Of Number

Of Input Parameters

- -

17 WS style mismat-

ching(Rpc or document)

InvalidOperationException The operation getMul could not be loaded because it speci�es rpc-style

in the literal mode

43

Nota-se que apenas 29% das exceções propagadas identi�caram os defeitos injetados

e que das 17 falhas simuladas, 12 não noti�caram a causa raiz do defeito injetado (este

total corresponde a 71% das falhas analisadas).

3.5.1 Análise de Correspondência

A Figura 15 quanti�ca e sumariza as mensagens de retorno propagadas nas exceções

das falhas analisadas.

Figura 15: Grá�co quantitativo das mensagens propagadas

3.5.1.1 Falhas compartilhando a mesma exceção e a mesma mensagem

Alguns grupos de exceções se formam por propagarem uma mesma informação acerca

da falha. Por exemplo, as falhas Network Connection breako�, Domain Name System

Down, Remote host unavailable e Application server is down propagam a mesma infor-

mação de falha (ver Tabela 2). Todas propagam um mesmo tipo de exceção: EndPointNot-

FoundException; as falhas Error in target namespace e Error in service operations name

também propagam uma mesma mensagem e um mesmo tipo de exceção: FaultException.

Dessa forma, torna-se inviável responder a exata origem da falha propagada.

No grupo das falhas Error in target namespace e Error in service operations name

é possível identi�car se ocorre a falha Error in target namespace veri�cando o endereço

da requisição disponível na mensagem propagada e checando a informação de namespace.

Caso esse não esteja correto, pode-se inferir que ocorreu a falha Error in target namespace.

Nesse grupo foi propagada a mensagem Server did not recognize the value of HTTP Header

44

SOAPAction: http://tempuri.org/getMul., onde tempuri.org é o namespace da requisição

em questão.

3.5.1.2 Falhas com informações exatas acerca da falha ocorrida

A falha Suspension of ws during transaction retornou uma exceção do tipo Com-

municationException e uma mensagem que descreve exatamente a falha provocada no

experimento. A falha System run-time error retornou uma exceção do tipo FaultExcep-

tion que representa uma falha SOAP, sem representar uma falha especí�ca, porém, a

mensagem retornada descreveu exatamente a falha simulada. A falha Application run-

time error ("Operand type mismatch") também retornou uma exceção FaultException,

mas a mensagem informa que a string estava em um formato incorreto. A falha WS style

mismatching retornou uma exceção do tipo InvalidOperationException e uma mensagem

que também descreve a falha provocada na abordagem.

3.5.1.3 Falhas que não geraram exceções no sistema

As falhas Output parameter type mismatch, Input parameter type mismatch, Error

in web service name e Error in service port name não geraram exceções no sistema,

retornando o resultado esperado e não propagando exceção. Especialmente as falhas Out-

put parameter type mismatch e Input parameter type mismatch não retornaram exceção

quando os valores enviados ou recebidos, mesmo não pertencendo ao tipo esperado, são

compatíveis com uma conversão.

Por exemplo: caso o método do serviço web getMul exija dois parâmetros inteiros e a

aplicação cliente forneça dois parâmetros do tipo string, o funcionamento dependerá do

valor dessa string. Caso sejam números válidos como 15, ou 2, a requisição funcionará

normalmente. Caso sejam valores como 15a ou 2b, ocorrerá uma falha de conversão que

será propagada de forma semelhante à falha Application runtime error ("Operand type

mismatch").

Já as falhas Error in web service name e Error in service port name não geraram

exceções porque os serviços web são invocados pela localização de endereços, enquanto o

nome do serviço e o nome da porta são utilizados apenas como informações suplementares

(GORBENKO et al., 2008).

Nas falhas Error in name of input parameter e Mismatching of number of input pa-

rams nenhuma exceção foi lançada pois o .NET, ao adicionar uma referência a um serviço

45

web, cria uma classe no arquivo Reference.cs que representa o serviço web e os parâmetros

dos seus métodos são representados como propriedades dessa classe, por isso, mesmo alte-

rando o nome do parâmetro ou comentando um dos parâmetros diretamente no método,

a exceção não ocorre pois a propriedade continuará existindo na classe que representa o

serviço web.

Por exemplo: caso seja modi�cado o nome do parâmetro no método, a exceção não

ocorre pois é realizado um mapeamento do novo nome do parâmetro com a propriedade da

classe que representa o parâmetro no serviço web. Caso seja comentado um dos parâme-

tros, será passado um valor nulo para a propriedade da classe que representa o parâmetro

comentado no serviço web. O que poderá ocorrer é uma falha interna no processamento

do serviço web no lado servidor por causa do valor nulo passado para o parâmetro e

que propagará uma falha semelhante à falha Application runtime error ("Operand type

mismatch").

3.5.1.4 Falha com retorno diferente de tipo da exceção

A falha Error Causing user-de�ned exception não retornou o tipo da exceção criada

pelo serviço, que foi o tipo UserException, conforme mostrado no código utilizado para

simular essa falha na Figura 13, retornando por sua vez um tipo FaultException, ou seja,

mesmo forçando a de�nição de um tipo para a exceção, como ela ocorreu internamente

no serviço web, o WCF a substituiu pelo tipo FaultException antes de propagá-la para

o cliente .NET. Contudo, a mensagem propagada foi a mesma mensagem con�gurada na

exceção original instanciada pelo serviço.

3.5.2 Análise de Desempenho

Segundo (GORBENKO et al., 2008), antes de uma exceção ser capturada pela aplicação

cliente, essa mesma exceção, durante seu lançamento, pode passar ao longo de vários

métodos. Esse processo demanda tempo e reduz o desempenho do tratamento de exceções

em uma arquitetura orientada a serviços. Esse caminho percorrido por uma exceção até

a sua captura pode ser analisado por meio da sua stack trace, uma característica comum

em mecanismos de tratamento de exceções de linguagens orientadas a objetos. A stack

trace mostra o caminho por onde a exceção passou (classes, métodos, trechos especí�cos

de código).

46

Figura 16: Trecho da stack trace da falha Domain Name System Down, simulada para a

plataforma .NET

A Tabela 3 apresenta os resultados da abordagem acerca da propagação de exceções

e do desempenho (tempo). A tabela inclui o número de métodos percorridos e o tempo

de delay, em ms, que representa o tempo contado antes da chamada até o momento da

captura em um bloco catch. A primeira linha representa uma execução normal, sem falhas,

apenas com o delay correspondente ao funcionamento normal da aplicação.

Para contabilizar o número de métodos percorridos utilizou-se o separador at contido

na stack trace e que aparece antecedendo um método retornado pela stack trace. A quan-

tidade de separadores presentes na stack trace foi utilizada para se determinar o número

de métodos percorridos.

Para o cálculo do delay foi inserido no código da aplicação cliente a instrução start =

DateTime.Now antes do try, guardando o horário inicial antes da chamada ao método do

serviço web, e também foi inserida a instrução end = DateTime.Now no código da aplica-

ção cliente após o catch, guardando o horário �nal após a exceção propagada. A diferença

entre o horário �nal e o horário inicial armazenados foi utilizada para se determinar o

delay da propagação de exceção.

47

Tabela 3: Análise de desempenho do mecanismo de propagação de exceções

Descrição da Falha Tipo da Exceção Métodos Delay

Without failure (Sem falha) - 0 46

Network connection break-o� EndpointNotFoundException 14 1.434

Domain Name System Down EndpointNotFoundException 14 1.175

Remote Host Unavailable EndpointNotFoundException 14 14.437

Application Server is Down EndpointNotFoundException 14 17.450

Suspension Of WS During Transaction CommunicationException 13 12.741

System Run-Time Error FaultException 10 314

Application run-time error FaultException 10 469

Error Causing user-de�ned exception FaultException 10 467

Error in Target Name Space FaultException 10 847

Error in service operations name FaultException 10 739

WS style mismatching InvalidOperationException 21 678

A Tabela 3 mostra que as falhas System run-time error, Application run-time error

("Operand type mismatch") e Error causing user-de�ned exception são as falhas com

menor tempo de espera até o retorno, isso se deve ao fato de que essas falhas não estão

atreladas a problemas de rede ou ligação. Todas elas pertencem à categoria de falhas de

serviço. A única exceção dessa categoria é a falha Suspension of ws during transaction

que trata exatamente de uma suspensão do serviço, o que faz a aplicação tentar a conexão

durante repetidas vezes até a falha se consolidar.

Foram analisadas as informações com o objetivo de identi�car possíveis pontos de

diferenciação entre falhas que propagam um mesmo tipo de exceção e mesma mensagem,

como nos grupos descritos na sessão anterior. Porém, foi percebido que o número de

métodos percorridos pela exceção propagada até ser capturada pelo catch se repetiu para

cada tipo de exceção gerada, independente da falha simulada.

As falhas Output parameter type mismatch, Input parameter type mismatch, Error in

name of input parameter, Mismatching of number of input params, Error in web service

name e Error in service port name não estão na tabela pois não retornaram nenhuma

exceção.

Falhas relacionadas a problemas de rede ou de ligação com o serviço geram um tempo

de espera até que a exceção seja capturada superior à falhas de sistema ou aplicação.

48

Muito disso em virtude de ser con�gurada nas infraestruturas de rede uma determinada

quantidade de tentativas a ser realizada para tentar se conectar a um determinado host.

Também se destaca a tentativa de manter uma conexão ativa para um determinado ser-

vidor, por um período de tempo con�gurado, antes de ser retornado um timeout para o

cliente.

Devem ser levados em consideração alguns fatores externos que podem ameaçar a

validade dos valores encontrados para o delay da propagação de exceção, principalmente

no que diz respeito aos valores altos retornados, em virtude de não se ter o controle total

do ambiente onde foram realizadas as simulações.

Como ameaça à validade pode-se destacar: a con�guração do hardware, da infraestru-

tura de rede e do poder de processamento das máquinas onde o cliente e o serviço estão

sendo executados, bem como se os mesmos estão na mesma rede ou em redes distintas e

qual é o meio de conexão entre essas redes.

Também podem ser ameaças à validade se o cliente e o serviço estão em máquinas

dedicadas ou compartilhando as suas execuções com outros serviços e processos que estão

rodando concorrentemente, tanto na máquina em que estão sendo executados, como no

tráfego que está passando pela rede no momento da execução.

3.5.3 Comparando com soluções em Java

As mensagens de exceção propagadas em cada uma das falhas testadas coletadas nesse

trabalho foram comparadas com as informações coletadas em (GORBENKO et al., 2008), de

acordo com os tipos de mensagens atribuídas às falhas analisadas e se elas conseguiram

ou não identi�car as falhas simuladas.

Apenas os resultados obtidos na análise de correspondência foram comparados, em

virtude da ameaça à validade descrita na seção anterior de uma possível comparação dos

resultados obtidos na análise de desempenho, pois não é possível garantir que os expe-

rimentos foram submetidos a uma mesma con�guração, o que afetaria em uma possível

variação encontrada no desempenho entre as plataformas.

A Tabela 4 mostra a relação entre os resultados obtidos na análise de serviços web

desenvolvidos na plataforma Java (GORBENKO et al., 2008) com os resultados obtidos nesse

trabalho, plataforma .NET. Os números na primeira coluna da Tabela 4 correspondem às

descrições das falhas especi�cadas na Tabela 2. O comportamento é dividido em falhas

que não foram identi�cadas, falhas identi�cadas e falhas que não geraram exceção.

49

Conforme é observado na Tabela 4, 8 das 17 falhas analisadas possuem o mesmo

resultado de acordo com as mensagens de exceção propagadas, tanto neste trabalho (pla-

taforma .NET), quanto em (GORBENKO et al., 2008) (plataforma Java), o que corresponde

a 47% das falhas analisadas.

Com tal resultado, nota-se que serviços web desenvolvidos em plataformas diferentes

comportam-se diferentemente em falhas semelhantes.

Tabela 4: Comparação dos resultados obtidos neste trabalho e (GORBENKO et al., 2008)

N◦ Comportamento .NET Comportamento (Java) Resultado

1 Não identi�cada Não identi�cada Igual




5 Identi�cada Não identi�cada Diferente

6 Identi�cada Identi�cada Igual



9 Não identi�cada Não gerou exceção Diferente

10 Não gerou exceção Não gerou exceção Igual


12 Não identi�cada Não gerou exceção Diferente


14 Não gerou exceção Não identi�cada Diferente

15 Não gerou exceção Identi�cada Diferente

16 Não gerou exceção Não identi�cada Diferente


50

4 EHWSNET: Uma solução para

Tratamento de Exceções no uso de

Serviços Web na plataforma .NET

Nesse capítulo é apresentada a biblioteca EHWSNET (Exception Handling in .NET

Web Services) desenvolvida no presente trabalho a partir dos resultados encontrados pela

abordagem realizada no capítulo anterior que indicou a necessidade do aperfeiçoamento

dos mecanismos de propagação de exceções no uso de serviços web em .NET. O escopo da

biblioteca é restrito às falhas analisadas nesse trabalho e aos resultados que propagaram

exceções de acordo com a abordagem realizada no capítulo 3.

4.1 Abordagem para a identi�cação das exceções pro-

pagadas

A abordagem para a identi�cação das exceções propagadas está representada pelo

diagrama de atividades da Figura 17, desenvolvido a partir dos resultados encontrados no

capítulo anterior e que será utilizado para identi�car as exceções propagadas.

51

Figura 17: Diagrama de atividades para a identi�cação das exceções propagadas

De acordo com os resultados encontrados no capítulo anterior e pelo diagrama de

atividades apresentado acima, é possível observar que retornaram quatro tipos de exce-

ções distintas (EndpointNotFoundException, FaultException, CommunicationException e

InvalidOperationException). A partir desses quatro tipos retornados, é separado o �uxo

do tratamento de exceção em quatro caminhos que o EHWSNET pode tomar para tratar

as exceções propagadas.

52

No grupo das exceções propagadas para o tipo EndpointNotFoundException, se en-

contram as falhas Network connection break-o�, Domain Name System Down, Remote

Host Unavailable e Application Server is Down, de acordo com os resultados do Capítulo

3. Analisando o comportamento das exceções propagadas para essas falhas, apresentado

no capítulo 3, percebe-se que elas retornaram a mesma mensagem e o mesmo número de

métodos percorridos desde a origem da propagação da exceção até elas serem capturadas

no topo da pilha pelo catch.

Só com essas informações, não se é possível distinguir as falhas para esse grupo. Por

isso, utilizou-se testes, de forma automática, sem a necessidade de intervenção humana,

para identi�car se o problema era na conexão de rede, no DNS ou na conectividade do

host, com a seguinte lógica: (i) primeiro é veri�cado se a conexão de rede está ativa, caso

não esteja, a falha retornada será Network connection break-o� ; (ii) caso a conexão de

rede esteja ativa, é veri�cado se o DNS consegue resolver o host onde está hospedado

o serviço web, caso não consiga, a falha retornada será Domain Name System Down;

(iii) caso o DNS resolva o host, é veri�cado a conectividade com o host através dos IPs

retornados pelo DNS, se a conexão não for estabelecida, a falha retornada será Remote

Host Unavailable e (iv) caso o teste de conectividade estabeleça a conexão, só restará a

falha associada ao servidor de aplicação, por isso a falha retornada será Application Server

is Down.

No grupo das exceções propagadas para o tipo FaultException, se encontram as falhas

System run-time error, Application run-time error, Error Causing user-de�ned exception,

Error in target namespace e Error in service operations name, de acordo com os resultados

do Capítulo 3. Analisando o comportamento das exceções propagadas para essas falhas,

apresentado no capítulo 3, de acordo com a mensagem da exceção, pode subdividir o grupo

em outros dois, onde no primeiro estarão as falhas System run-time error, Application run-

time error e Error Causing user-de�ned exception e no segundo as falhas Error in target

namespace e Error in service operations name.

Como no primeiro subgrupo gerado todas as exceções retornam informações exatas

acerca da falha ocorrida, a mensagem original será retornada. No segundo subgrupo ge-

rado, as exceções propagadas retornam a mesma mensagem, porém, é possível identi�car

se ocorre a falha Error in target namespace veri�cando o endereço da requisição disponí-

vel na mensagem propagada e checando a informação de namespace. Caso essa não esteja

correta, pode-se inferir que ocorreu a falha Error in target namespace, caso contrário,

pode-se inferir que ocorreu a falha Error in service operations name.

53

No grupo das exceções propagadas para o tipo CommunicationException, se encontra

a falha Suspension of WS during transaction, de acordo com os resultados do Capítulo 3.

Como, para essa falha, a exceção propagada retornou a informação exata acerca da falha

ocorrida, de acordo com os resultados apresentados no capítulo 3, a mensagem original

será retornada.

No grupo das exceções propagadas para o tipo InvalidOperationException, se encontra

a falhaWS style mismatching, de acordo com os resultados do Capítulo 3. Como, para essa

falha, a exceção propagada também retorna a informação exata acerca da falha ocorrida,

de acordo com os resultados apresentados no capítulo 3, a mensagem original também

será retornada.

4.2 DLL ModuloTratador

Para tratar as exceções propagadas, foi desenvolvida uma DLL (Dynamic Link Li-

brary) chamada ModuloTratador que implementa os passos descritos na seção anterior,

com 69 LOC (Lines Of Code), calculadas através da ferramenta Analyze presente no Vi-

sual Studio 2010. Essa DLL poderá ser utilizada por qualquer aplicação .NET que trabalhe

com a arquitetura WCF.

A DLLModuloTratador tem um método público chamado TratarExcecao que receberá

como parâmetros de entrada a exceção propagada, o host e a porta do serviço web que

se está tentando acessar, para os testes de DNS e conectividade do host, bem como o

namespace, obtido do binding com o serviço, para veri�cação e terá como saída a exceção

tratada com a mensagem informando a falha ocorrida.

54

Figura 18: Diagrama de classe da DLL ModuloTratador

Dentro do método TratarExcecao, inicialmente, são obtidos os valores correspondentes

ao tipo e a mensagem da exceção propagada. Informações essas que serão usadas no

decorrer do método. Após isso, a separação pelo tipo da exceção é realizada.

4.2.1 Tratamento para o tipo EndpointNotFoundException

Caso o tipo da exceção seja EndpointNotFoundException, será veri�cado inicialmente,

através do método AchouMensagem, se a mensagem propagada na corrente transação está

entre as mensagens a serem analisadas para as falhas do tipo da exceção em questão dentro

do escopo do presente trabalho. O método AchouMensagem será explicado na seção 4.2.5.

Se a mensagem propagada na corrente transação estiver entre as mensagens a serem

analisadas para as falhas do tipo da exceção em questão, é realizado o teste de conexão

de rede, através da função InternetGetConnectedState e os testes de DNS e de conecti-

vidade do host, através do método TesteDNSeConectividadeHost, para se determinar a

falha ocorrida de acordo com a lógica e os passos descritos na seção 4.1 para o tipo da

exceção EndpointNotFoundException. A função InternetGetConnectedState e o método

TesteDNSeConectividadeHost serão explicados nas seções logo abaixo.

4.2.1.1 Função InternetGetConnectedState

Para o teste de conexão de rede se usou a função InternetGetConnectedState da API

(Application Programming Interface) do Windows, acessada através da DLL wininet.dll.

55

A função InternetGetConnectedState retorna o estado da conexão do sistema (CENTER,

2014). O valor true será retornado se existir uma conexão ativa via modem ou via LAN (

Local Area Network) e retornará false se não existir uma conexão internet ou se todas as

possibilidades de conexão internet não estejam ativas. O valor true retornado indica que

pelo menos uma conexão com a internet está disponível, ele não garante que uma conexão

para um host especí�co pode ser estabelecida (CENTER, 2014).

4.2.1.2 Método TesteDNSeConectividadeHost

Para os testes de DNS e de conectividade do host foi desenvolvido o método Tes-

teDNSeConectividadeHost. Nele, se testa primeiro o DNS, através do método TesteDns,

também desenvolvido, caso o DNS não esteja resolvendo o host, a conectividade com o

host não é testada, já retornando que a falha é no DNS.

Caso o DNS esteja resolvendo o host, são pegos todos os IPs retornados pelo DNS

para o host remoto e são realizados testes de conectividade com cada um deles, garantindo

assim também o teste de balanceamento de carga. Se algum teste de conectividade com

os IPs retornados pelo DNS falhar, será retornado que a falha é Remote Host Unavailable,

informando também o IP onde ocorreu o problema, com a sua respectiva porta onde se

tentou o acesso. Se não ocorrerem falhas nos testes de conectividade, o método retornará

OK.

No método TesteDns se usou o método GetHostEntry, que resolve um nome de host

e retorna todos os IPs associados a ele, da classe System.Net.DNS do .NET, classe essa

responsável por realizar operações com o DNS (DNS, 2014). Além de retornar os IPs, o

método também foi utilizado para determinar se o DNS está funcionando ou não. Por

exemplo, caso ocorra uma exceção na hora de recuperar os IPs, será retornado false, caso

não ocorra exceção, será retornado true.

Para os testes de conectividade se usou o método Connect da classe System.Net.Sockets

do .NET, método esse que estabelece uma conexão a um host remoto (SOCKET, 2014).

4.2.2 Tratamento para o tipo FaultException

Caso o tipo da exceção seja FaultException, assim como no caso do tipo Endpoint-

NotFoundException, será veri�cado inicialmente, através do método AchouMensagem, se

a mensagem propagada na corrente transação está entre as mensagens a serem analisadas

para o tipo da exceção em questão dentro do escopo do presente trabalho.

56

Passando pela veri�cação da mensagem, é veri�cado em seguida se a mensagem propa-

gada faz parte do grupo que retorna as informações exatas acerca da falha ocorrida. Essa

veri�cação é realizada através da substring Server was unable to process request, retor-

nada para esses casos, de acordo com os resultados encontrados na abordagem realizada

no capítulo 3.

Caso a mensagem faça parte desse grupo, a mensagem original será retornada, caso

contrário, será veri�cado o endereço da requisição disponível na mensagem propagada

para checar a informação de namespace. Caso esse não esteja correto, a falha Error in

target namespace será retornada, caso contrário, se retornará a falha Error in service

operations name.

4.2.3 Tratamento para o tipo CommunicationException

Caso o tipo da exceção seja CommunicationException, assim como feito para os outros

dois tipos, será veri�cado inicialmente, através do método AchouMensagem, se a mensa-

gem propagada na corrente transação está entre as mensagens a serem analisadas para o

tipo da exceção em questão dentro do escopo do presente trabalho.

Passando pela veri�cação da mensagem, como a mensagem propagada faz parte do

grupo que retorna as informações exatas acerca da falha ocorrida, a exceção original será

retornada.

4.2.4 Tratamento para o tipo InvalidOperationException

Caso o tipo da exceção seja InvalidOperationException, assim como feito para os

demais tipos, será veri�cado inicialmente, através do método AchouMensagem, se a men-

sagem propagada na corrente transação está entre as mensagens a serem analisadas para

o tipo da exceção em questão dentro do escopo do presente trabalho.

Passando pela veri�cação da mensagem, como a mensagem propagada faz parte do

grupo que retorna as informações exatas acerca da falha ocorrida, a exceção original será

retornada.

4.2.5 Método AchouMensagem

Como mostrado nas seções anteriores, o método AchouMensagem é utilizado no trata-

mento dos quatro tipos (EndpointNotFoundException, FaultException, CommunicationEx-

57

ception e InvalidOperationException) e a sua função é procurar se a mensagem propagada

na corrente transação está entre as mensagens encontradas para a análise da falha ocorrida

de acordo com os resultados encontrados no capítulo 3 do presente trabalho. Ele receberá

como parâmetros de entrada um enumerado que indicará para qual tipo de exceção se

quer procurar as mensagens propagadas para análise e a mensagem da corrente transação.

As mensagens propagadas encontradas para a análise da falha ocorrida estarão orga-

nizadas em um arquivo XML chamado XMLPROPAGACOES.xml e a sua estrutura será

explicada na próxima seção.

Após o método AchouMensagem carregar as informações do arquivo XML, será utili-

zado um dicionário de dados onde estarão guardadas as falhas ocorridas e suas respectivas

mensagens para o tipo da exceção em questão. Informações essas que serão extraídas a

partir do arquivo XMLPROPAGACOES.xml pelo método CarregarFalhasMensagens que

será explicado na seção 4.2.5.2.

Após o dicionário de dados preenchido, o método AchouMensagem veri�cará se en-

tre as mensagens armazenadas no dicionário de dados está a mensagem propagada na

corrente transação. Se a mensagem for encontrada, será retornado true, indicando que a

mensagem propagada está entre as selecionadas para análise, caso contrário, será retor-

nado false, indicando que a mensagem propagada não foi encontrada entre as selecionadas

para análise.

4.2.5.1 Arquivo XMLPROPAGACOES.xml

Como dito na seção anterior, o arquivo XMLPROPAGACOES.xml será o local onde

estarão guardadas as mensagens propagadas que serão analisadas de acordo com as falhas

ocorridas e os tipos de exceção gerada. Todas as mensagens organizadas a partir dos

resultados encontrados na abordagem do capítulo 3.

A estrutura do arquivo XMLPROPAGACOES.xml começará pelo grupo das exce-

ções, que conterá os grupos para cada tipo de exceção, esses conterão os grupos das suas

respectivas falhas que, por �m, terão os elementos que guardarão as partes �xas de suas

respectivas mensagens a serem analisadas.

As Figuras 19, 20, 21, 22 e 23 exempli�cam a estrutura do arquivo, o grupo Endpoint-

NotFoundException, o grupo FaultException, o grupo CommunicationException e o grupo

InvalidOperationException, respectivamente.

58

Figura 19: Exemplo estrutura do arquivo XMLPROPAGACOES.xml

Figura 20: Exemplo grupo XML ENDPOINTNOTFOUNDEXCEPTION

Figura 21: Exemplo grupo XML FAULTEXCEPTION

59

Figura 22: Exemplo grupo XML COMMUNICATIONEXCEPTION

Figura 23: Exemplo grupo XML INVALIDOPERATIONEXCEPTION

4.2.5.2 Método CarregarFalhasMensagens

Como dito anteriormente, o método CarregarFalhasMensagens é utilizado para ex-

trair, a partir do arquivo XMLPROPAGACOES.xml, as falhas e suas respectivas men-

sagens que se deseja analisar para um determinado tipo de exceção. Ele receberá como

parâmetros de entrada o conteúdo completo do arquivo XMLPROPAGACOES.xml e o

valor do enumerado pelo qual será feito a busca pelo tipo da exceção e retornará um di-

cionário de dados onde o seu conteúdo será as falhas com as suas respectivas mensagens.

4.3 Utilizando AOP

No .NET o programador não é obrigado a declarar as exceções (CABRAL; MARQUES,

2007). Para que o programador não insira manualmente no seu código blocos try e catch

em todas as chamadas aos métodos dos serviços web de sua aplicação para capturar

a exceção propagada e passá-la para a DLL ModuloTratador tratá-la, foi utilizado um

aspecto para realizar esse trabalho para o programador de forma automática, diminuindo

o seu esforço de manutenção.

O conceito de AOP (Aspect-oriented Programming) oferece uma alternativa interes-

sante para a especi�cação de componentes não funcionais (ex: tolerância à falhas), bem

como outros conceitos transversais. Essas implementações são chamadas de aspectos e em

60

um determinado ponto de junção se entrelaça com a outra parte funcional do software

(SCHULT, 2014).

O uso de AOP não é nativo no framework .NET (SCHULT, 2014). Para promover o

uso de AOP no contexto do framework .NET, se recorreu à biblioteca LOOM.NET, que

tem exatamente esse objetivo (SCHULT, 2014). A biblioteca LOOM.NET permite de�nir

um código de aspecto na forma de uma classe .NET, herdando da classe AspectAttribute,

de�nindo os pontos de junção para as classes alvo, que são as classes regulares do .NET

(SCHULT, 2014).

Para injetar os blocos try e os catch e a chamada à DLL ModuloTratador, foi criado

o aspecto AspectoTratador utilizando as anotações [Call(Advice.Around)] e [IncludeAll]

do LOOM.NET, garantindo que o aspecto seja injetado em torno do método chamado

no contexto da classe alvo e que ele seja injetado em todos os métodos da classe alvo

inspecionada, respectivamente (SCHULT, 2014).

Para capturar os valores do host, da porta e do namespace necessários para alguns

testes internos da DLL ModuloTratador, foi utilizada a propriedade Endpoint do objeto

presente no contexto responsável pela chamada ao serviço web onde os valores estão

armazenados. A Figura 24 mostra o aspecto AspectoTratador criado.

Figura 24: Aspecto AspectoTratador

Com o aspecto criado, para que o seu código seja injetado na classe alvo, utiliza-se o

nome do aspecto criado, no caso do EHWSNET, será AspectoTratador, como uma ano-

tação na classe alvo a ser inspecionada (SCHULT, 2014). No .NET a classe que representa

61

o serviço web �ca no arquivo Reference.cs (MSDN, 2014), encontrado no diretório padrão

onde o .NET armazena as referências aos serviços web. Colocando a anotação no topo

desse arquivo, os métodos do serviço web serão inspecionados, conforme exempli�cado

pela Figura 25.

Figura 25: Anotação AspectoTratador

Ao compilar a aplicação cliente, o LOOM.NET altera o assembly da aplicação, entre-

laçando o aspecto com a classe alvo, para que os try e os catch sejam injetados quando o

método do serviço web for executado (SCHULT, 2014).

Caso o desenvolvedor não tenha autorização do seu gerente para o uso de aspectos, em

virtude do mesmo alterar o bytecode da aplicação, ele poderá ainda utilizar o EHWSNET

referenciando diretamente à DLL ModuloTratador no código de sua aplicação, mas, para

isso, o desenvolvedor terá que manualmente colocar os try e os catch nas chamadas para

os métodos do serviço web que ele deseja tratar, chamar manualmente o método Trata-

rExcecao da DLL e passar manualmente a exceção e os demais parâmetros necessários

para o funcionamento da DLL, alterando o código fonte de sua aplicação e aumentando

o seu esforço de manutenção, o que não se é desejado.

62

5 Avaliação da solução EHWSNET

Nesse capítulo será avaliada a solução EHWSNET. Para avaliar a solução, foram

simuladas as falhas que propagaram exceções de acordo com a abordagem realizada e

foi analisado o seu comportamento no uso dos serviços web da GNRE (Guia Nacional de

Recolhimento de Tributos Estaduais) on-line e do compartilhamento de NF-e (Nota Fiscal

eletrônica) com o DETRAN/RN (Departamento Estadual de Trânsito do Rio Grande do

Norte) nos servidores de homologação da SET/RN (Secretaria de Estado da Tributação

do Estado do Rio Grande do Norte) em estudos de caso com soluções reais.

5.1 Objetivo da avaliação

O objetivo dessa avaliação é submeter as aplicações da GNRE on-line e do compar-

tilhamento da NF-e com o DETRAN/RN às falhas simuladas que propagaram exceções

de acordo com a abordagem realizada no presente trabalho. Analisando o seu comporta-

mento com relação às mensagens propagadas antes e depois do uso do EHWSNET para

veri�car se a solução conseguiu identi�car a falha testada. Como objetivos secundários,

também se pretende analisar o delay para a identi�cação da falha pelo EHWSNET e a

modularidade (ganho na manutenabilidade) do código para o desenvolvedor.

Para atingir esses objetivos, três questões foram elaboradas: (i) o EHWSNET conse-

guiu identi�car as falhas simuladas?; (ii) o delay da propagação de exceção com o uso do

EHWSNET é aceitável?; (iii) ocorreu um ganho na modularidade do código com o uso do

EHWSNET?

Como métricas utilizadas para responder a primeira questão se tem as mensagens

propagadas antes e depois do uso do EHWSNET. O delay da propagação de exceção

antes e depois do uso do EHWSNET foi utilizado como métrica para responder a segunda

questão.

Como métricas para se determinar a modularidade da solução, respondendo a terceira

63

questão, foram utilizadas a CDC (Concern Di�usion over Components), a CDO (Concern

Di�usion over Operations) e a CDLOC (Concern Di�usion over LOC ). Essas métricas

foram selecionadas pois elas foram aplicadas em uma série de estudos de caso envolvendo

modularidade com AOP (SANTANNA et al., 2003).

A métrica CDC conta o número de classes e aspectos que contribuem parcialmente,

ou totalmente, para a implementação de um conceito. A ideia é capturar todos os com-

ponentes que têm alguma in�uência de certo conceito, permitindo assim avaliar o grau de

dispersão (SANTANNA et al., 2003).

Similar à CDC, a métrica CDO conta o número de métodos, construtores e advices

que contribuem para a implementação de um conceito. O objetivo é quanti�car quan-

tos componentes internos são necessários para a concretização de um conceito especí�co

(SANTANNA et al., 2003).

A métrica CDLOC conta o número de pontos de transição para cada conceito através

das linhas de código. Pontos de transição são pontos no código onde existe um entrelaça-

mento do conceito (SANTANNA et al., 2003).

O processo de medição foi realizado de forma manual, contabilizando a quantidade de

locais que os métodos dos serviços web eram chamados nos códigos fontes das aplicações,

levando-se em consideração o esforço do programador para a inserção dos try e dos catch

de forma manual (sem o EHWSNET) e de forma automática (com o EHWSNET) em

cada método.

5.2 Con�guração do ambiente de avaliação

Na con�guração do ambiente para a avaliação, a máquina que respondeu como cliente

possuía 2 cores Intel Xeon 2.0 GHz (por core), com 10 GB de RAM e sistema operacional

Windows Server 2008 R2 x64. A máquina utilizada como servidora foi uma Windows

Server 2008 R2 x64, com 16GB de RAM e possuía 4 cores Intel Xeon 3.2 GHz (por core).

5.3 Uso do EHWSNET com o serviço web da GNRE

on-line

O Projeto GNRE Online teve como objetivo a implantação de um modelo nacional de

recolhimento eletrônico para validação e emissão padronizada da GNRE e foi desenvolvido,

64

de forma integrada, pelas secretarias de fazenda/tributação dos estados com a coordenação

da SEFAZ/PE (Secretaria da Fazenda do Estado de Pernambuco)(SEFAZ/PE, 2010).

De forma conceitual, o aplicativo cliente consome o serviço web da GNRE da UF

(Unidade da Federação) da secretaria em questão, digita as informações necessárias e, de

acordo com as informações passadas, o método do serviço web da UF da secretaria da

requisição valida, emite ou consulta uma GNRE (SEFAZ/PE, 2010). A Figura 26, retirada

de (SEFAZ/PE, 2010), exempli�ca o modelo conceitual.

Figura 26: Modelo conceitual da GNRE on-line (SEFAZ/PE, 2010)

Como cliente para a avaliação foi utilizada a aplicação web da GNRE on-line de

homologação da SET/RN responsável por simular o ambiente de produção do portal da

GNRE on-line ao consumir o serviço web do RN (Rio Grande do Norte), hospedado na

SET/RN. A aplicação web utilizada como cliente foi desenvolvida utilizando a linguagem

C# e atualmente se encontra na versão 4.0 do framework .NET, possuindo atualmente

2298 LOC (Lines Of Code), calculadas através da ferramenta Analyze presente no Visual

Studio 2010.

No cliente, foi adicionado ao projeto o aspecto AspectoTratador, mostrada na seção 4.3,

pela Figura 24, e foi colocada no topo do arquivo Reference.cs a anotação AspectoTratador,

conforme também exempli�cado na seção 4.3, pela Figura 25. No restante do código da

aplicação, o desenvolvedor não precisou realizar alterações.

No serviço web, para poder simular as falhas System Run-Time Error, Application

run-time error e Error Causing user-de�ned exception, foi necessário criar um novo mé-

todo no serviço, semelhante ao método getMul utilizado na abordagem do capítulo 3 para

propagá-las. A necessidade se deu pelo fato de toda a inteligência do serviço se encontrar

em procedures de banco de dados. O tratamento para as falhas System Run-Time Error

e Application run-time error estava sendo realizado internamente no banco, retornando

para a camada do serviço web apenas uma string com o erro interno do banco, não propa-

gando uma exceção para a aplicação cliente. No caso da falha Error Causing user-de�ned

65

exception, a necessidade foi pelo fato do serviço não possuir uma exceção implementada.

Essas exceções tiveram que ser injetadas para que fosse possível avaliar todo o escopo da

biblioteca proposta.

5.3.1 Análise do comportamento

O serviço web da GNRE on-line foi submetido às falhas simuladas que propagaram

exceções de acordo com a abordagem realizada no presente trabalho e foi analisado o seu

comportamento com relação às mensagens propagadas antes e depois do uso do EHWS-

NET para veri�car se a solução conseguiu identi�car a falha testada. A Tabela 5 mostra os

resultados encontrados com relação às mensagens retornadas com e sem o uso do EHWS-

NET. A Tabela 6 mostra o tempo de retorno (Delay) que o cliente levou para propagar

a exceção, tempo gasto pelo cliente para propagar a exceção com e sem o uso do EHWS-

NET. Para o cálculo do tempo gasto da propagação foi utilizada a mesma abordagem

apresentada na seção 3.5.2.

66

Tabela 5: Análise do comportamento no uso do EHWSNET com o serviço web da GNRE

on-lineFalha Mensagem sem o EHWSNET Mensagem com o EHWSNET

Network connection break-o� There was no endpoint lis-

tening at http://set-srv-

desenv/WebServices/GnreRecepcao.asmx

that could accept the message. This is often

caused by an incorrect address or SOAP

action. See InnerException, if present, for

more details.

Network connection break-o�

Domain Name System Down There was no endpoint lis-






more details.

Domain Name System Down

Remote Host Unavailable There was no endpoint lis-






more details.

Remote Host Unavailable => 10.2.2.198:80

Application Server is Down There was no endpoint lis-






more details.

Application Server is Down

Suspension of WS during transaction An error occurred while receiving

the HTTP response to http://set-srv-

desenv/WebServices/GnreRecepcao.asmx.

This could be due to the service endpoint

binding not using the HTTP protocol. This

could also be due to an HTTP request con-

text being aborted by the server (possibly

due to the services shutting down). See

server logs for more details.

An error occurred while receiving


desenv/WebServices/GnreRecepcao.asmx.



could also be due to an HTTP request con-

text being aborted by the server (possibly

due to the services shutting down). See

server logs for more details.

System run-time error Server was unable to process request. �

>System.DivideByZeroException: Attemp-

ted to divide by zero.

Server was unable to process request. �

>System.DivideByZeroException: Attemp-

ted to divide by zero.

Application run-time error Server was unable to process request. �

>System.FormatException: Input string was

not in a correct format.




Error Causing user-de�ned exception Server was unable to process request. �

>WebServices.UserException: Exception th-

rowed to test error 9. Propagation of an user

de�ned exception.




de�ned exception.

Error in target namespace Server did not recognize the va-

lue of HTTP Header SOAP Action:

http://tempur.org/processar.

Error in Target NameSpace

Error in service operations name Server did not recognize the va-


http://tempuri.org/processar

Error in service operations name

WS style mismatching The operation processar could not be loaded

because it speci�es rpc-style in the literal

mode

The operation processar could not be loaded

because it speci�es rpc-style in the literal

mode

67

Tabela 6: Análise do Delay(ms) no uso do EHWSNET com o serviço web da GNRE on-line

Falha Sem o EHWSNET Com o EHWSNET

Network connection break-

o�

1.106 1.599

Domain Name System

Down

0.810 1.153

Remote Host Unavailable 1.481 2.963

Application Server is Down 2.272 2.837

Suspension of WS during

transaction

14.378 14.730

System run-time error 0.300 0.444

Application run-time error 0.104 0.172

Error Causing user-de�ned

exception

0.335 0.467

Error in target namespace 0.894 1.354

Error in service operations

name

0.749 1.197

WS style mismatching 0.489 0.672

Conforme observado pela Tabela 5, o EHWSNET conseguiu identi�car todas as falhas

simuladas que geraram exceções de acordo com a abordagem do presente trabalho no uso

do serviço web da GNRE on-line e retornou a informação exata da falha ocorrida.

Analisando o Delay para a identi�cação da falha pelo EHWSNET na Tabela 6, as

falhas relacionadas a problemas de rede (Network connection break-o�, Domain Name

System Down, Remote Host Unavailable e Application Server is Down) são as falhas com

maior tempo, em virtude dos testes necessários feito pela solução para identi�cá-las.

Vale ressaltar que os valores obtidos para o Delay sofrem in�uência da con�guração

do hardware, da infraestrutura de rede e do poder de processamento das máquinas onde

o cliente e o serviço estão sendo executados. Também se deve levar em consideração se o

cliente e o servidor estão na mesma rede ou em redes distintas e se eles estão em máquinas

dedicadas ou compartilhando as suas execuções com outros serviços e processos que estão

rodando concorrentemente. O tráfego que está passando pela rede no momento da execu-

68

ção também deve ser considerado. Portanto, não sendo assim um ambiente controlado.

5.3.2 Modularidade

Foram analisadas manualmente as classes que compõem a aplicação web da GNRE on-

line da SET/RN para contabilizar a quantidade de locais que os métodos do serviço web

eram chamados no código fonte da aplicação e assim determinar os valores das métricas

CDC, CDO e CDLOC, sem o uso do EHWSNET e com o uso do EHWSNET.

Foram encontradas 7 chamadas aos métodos do serviço web, todas concentradas em

uma única classe. Nesse cenário, levando-se em consideração a inserção dos try e dos catch

para cada chamada aos métodos do serviço web, sem o uso do EHWSNET, a CDC tem o

valor de 1, pois apenas uma classe é alterada, a CDO tem o valor de 7, pois 7 chamadas

aos métodos são alteradas e a CDLOC terá o valor de 28.

Usando o EHWSNET, a CDC tem o valor de 2, pois a classe aspecto e o arquivo

Reference.cs são alterados para a inserção dos try e dos catch, a CDO tem o valor de

1, pois apenas a chamada ao método dentro da classe aspecto precisa ser alterada, e a

CDLOC tem o valor de 2. A Tabela 7 resume os valores encontrados para a CDC, CDO

e CDLOC, relacionando-as sem e com o uso do EHWSNET.

Tabela 7: Modularidade do EHWSNET com a aplicação web da GNRE on-line

Métrica Sem o EHWSNET Com o EHWSNET

CDC 1 2

CDO 7 1

CDLOC 28 2

O resultado apresentado pela Tabela 7 mostra a vantagem do uso do EHWSNET com

relação à modularidade, pois apesar da métrica CDC ter sido maior para o cenário da

aplicação da GNRE on-line, teve-se um ganho nas métricas CDO e CDLOC, onde elas

foram reduzidas de 7 para 1 e de 28 para 2, respectivamente, re�etindo um ganho na

manutenabilidade do código para o desenvolvedor.

69

5.4 Uso do EHWSNET com o serviço web do Compar-

tilhamento de NF-e com o DETRAN/RN

O Projeto NF-e teve como objetivo a implantação de um modelo nacional de docu-

mento �scal eletrônico visando a substituição da sistemática de emissão do documento

�scal em papel, permitindo, ao mesmo tempo, o acompanhamento em tempo real das

operações comerciais pelo Fisco (ENCAT, 2008).

O processo de compartilhamento de informações é um requisito básico e de funda-

mental importância para o sucesso do projeto (ENCAT, 2008). O órgão da administração

tributária que autoriza o uso da NF-e tem a responsabilidade de compartilhá-la com os

demais órgãos conveniados que tenham o legítimo interesse em recebê-la (ENCAT, 2008).

A SET/RN faz parte dos órgãos autorizadores e o DETRAN/RN está incluído entre os

órgãos recebedores.

A Figura 27, retirada de (ENCAT, 2008), exempli�ca o modelo conceitual do compar-

tilhamento da NF-e entre a SET/RN e o DETRAN/RN, onde se tem: em 1, a aplicação

responsável pelos processos dos veículos no DETRAN (DetranNet) capturando as NF-es

através de uma aplicação .NET externa; em 2, a aplicação .NET responsável pela captura

das NF-es consome um serviço web hospedado na SET/RN que fornecerá a NF-e em ques-

tão a partir da sua base em 3; em 4, a aplicação .NET alimentará a base do DetranNet

com a NF-e capturada da SET/RN que será utilizada pela aplicação DetranNet em 5.

70

Figura 27: Modelo conceitual do compartilhamento da NF-e entre a SET/RN e o DETRAN/RN

(ENCAT, 2008)

Como cliente para a avaliação foi solicitado ao DETRAN/RN a aplicação .NET res-

ponsável pelas capturas das NF-es e que consome o serviço web hospedado na SET/RN.

A aplicação foi publicada no servidor de homologação da SET/RN para que a avaliação

fosse realizada. A aplicação web repassada pelo DETRAN/RN e utilizada como cliente foi

desenvolvida utilizando a linguagem C# e atualmente se encontra na versão 4.0 do fra-

mework .NET, possuindo atualmente 1796 LOC, calculadas através da ferramenta Analyze

presente no Visual Studio 2010.

No cliente, assim como no caso da GNRE on-line, foi adicionado ao projeto o aspecto

AspectoTratador, mostrada na seção 4.3, pela Figura 24, e foi colocada no topo do ar-

quivo Reference.cs a anotação AspectoTratador. No restante do código da aplicação, o

desenvolvedor não precisou realizar alterações.

No serviço web, assim como no caso da GNRE on-line, para poder simular as falhas

System Run-Time Error, Application run-time error e Error Causing user-de�ned ex-

ception, também foi necessário criar um novo método no serviço, semelhante ao método

getMul utilizado na abordagem do capítulo 3 para propagá-las, pelos mesmos motivos

expostos para o caso da GNRE on-line.

71

5.4.1 Análise do comportamento

O serviço web do compartilhamento NF-e/DETRAN foi submetido às falhas simula-

das que propagaram exceções de acordo com a abordagem realizada no presente trabalho

e também foi analisado o seu comportamento com relação às mensagens propagadas antes

e depois do uso do EHWSNET para veri�car se a solução conseguiu identi�car a falha

testada. A Tabela 8 mostra os resultados encontrados com relação às mensagens retorna-

das com e sem o uso do EHWSNET. A Tabela 9 mostra o tempo de retorno (Delay) que

o cliente levou para propagar a exceção, calculado da mesma forma que foi feito para o

caso da GNRE on-line.

72

Tabela 8: Análise do comportamento do uso do EHWSNET com o serviço web do comparti-

lhamento NF-e/DETRANFalha Mensagem sem o EHWSNET Mensagem com o EHWSNET

Network connection break-o� There was no endpoint lis-


desenv/WebServices/WsIntegracaoDetran.asmx




more details.

Network connection break-o�

Domain Name System Down There was no endpoint lis-






more details.

Domain Name System Down

Remote Host Unavailable There was no endpoint lis-






more details.

Remote Host Unavailable => 10.2.2.198:80

Application Server is Down There was no endpoint lis-






more details.

Application Server is Down

Suspension of WS during transaction An error occurred while receiving


desenv/WebServices/WsIntegracaoDetran.asmx.



could also be due to an HTTP request context

being aborted by the server (possibly due to

the services shutting down). See server logs

for more details.

An error occurred while receiving


desenv/WebServices/WsIntegracaoDetran.asmx.



could also be due to an HTTP request context

being aborted by the server (possibly due to

the services shutting down). See server logs

for more details.

System run-time error Server was unable to process request. �

>System.DivideByZeroException: Attempted

to divide by zero.


>System.DivideByZeroException: Attempted

to divide by zero.

Application run-time error Server was unable to process request. �






Error Causing user-de�ned exception Server was unable to process request. �



de�ned exception.




de�ned exception.

Error in target namespace Server did not recognize the va-


http://tempur.org/consultaNFe

Error in Target NameSpace

Error in service operations name Server did not recognize the va-


http://tempuri.org/consultaNFe

Error in service operations name

WS style mismatching The operation consultaNFe could not be loa-

ded because it speci�es rpc-style in the literal

mode

The operation consultaNFe could not be loa-

ded because it speci�es rpc-style in the literal

mode

73

Tabela 9: Análise do Delay(ms) no uso do EHWSNET com o serviço web do compartilhamento

NF-e/DETRAN

Falha Sem o EHWSNET Com o EHWSNET

Network connection break-

o�

1.434 1.908

Domain Name System

Down

0.782 1.175

Remote Host Unavailable 1.696 2.525

Application Server is Down 4.709 5.160

Suspension of WS during

transaction

14.378 14.622

System run-time error 0.260 0.986

Application run-time error 0.469 0.861

Error Causing user-de�ned

exception

0.335 0.476

Error in target namespace 0.450 0.847

Error in service operations

name

1.083 1.479

WS style mismatching 0.175 0.677

Conforme observado pela Tabela 8, assim como no caso da GNRE on-line, o EHWS-

NET conseguiu identi�car as falhas simuladas que geraram exceções de acordo com a abor-

dagem do presente trabalho no uso do serviço web do compartilhamento NF-e/DETRAN.

Os Delays encontrados na Tabela 9 seguiram a tendência explicada anteriormente na seção

5.3.1 para o caso da GNRE on-line.

5.4.2 Modularidade

Foram analisadas manualmente as classes que compõem a aplicação web do comparti-

lhamento da NF-e para contabilizar a quantidade de locais que os métodos do serviço web

eram chamados no código fonte da aplicação e assim determinar os valores das métricas

CDC, CDO e CDLOC sem o uso do EHWSNET e com o uso do EHWSNET.

74

Foram encontradas 5 chamadas aos métodos do serviço web, todas concentradas em

uma única classe. Nesse cenário, levando-se em consideração a inserção dos try e dos catch

para cada chamada aos métodos do serviço web, sem o uso do EHWSNET, a CDC tem o

valor de 1, pois apenas uma classe é alterada, a CDO tem o valor de 5, pois 5 chamadas

aos métodos são alteradas e a CDLOC terá o valor de 20.

Usando o EHWSNET, assim como no caso da GNRE on-line, a CDC tem o valor de 2,

pois a classe aspecto e o arquivo Reference.cs são alterados para a inserção dos try e dos

catch, a CDO tem o valor de 1, pois apenas a chamada ao método dentro da classe aspecto

é alterada, e a CDLOC terá o valor de 2. A Tabela 10 resume os valores encontrados para

a CDC, CDO e CDLOC, relacionando-as sem e com o uso da solução.

Tabela 10: Modularidade do EHWSNET com a aplicação web do compartilhamento de NF-e

com o DETRAN/RN

Métrica Sem o EHWSNET Com o EHWSNET

CDC 1 2

CDO 5 1

CDLOC 20 2

Assim como no caso da GNRE on-line, o resultado mostra a vantagem do EHWSNET

com relação à modularidade para o compartilhamento de NF-e com o DETRAN/RN, pois

apesar da métrica CDC ter sido maior para o cenário da aplicação do compartilhamento,

teve-se um ganho nas métricas CDO e CDLOC, onde elas foram reduzidas de 5 para 1

e de 20 para 2, respectivamente, re�etindo também um ganho na manutenibilidade do

código para o desenvolvedor.

5.5 Conclusões

Conforme observado pelos resultados encontrados, tanto no caso da GNRE on-line,

quanto no caso do compartilhamento da NF-e com o DETRAN/RN, o EHWSNET con-

seguiu determinar a falha ocorrida, atingindo o objetivo principal desse trabalho e res-

pondendo o primeiro questionamento. Também foi observado que ocorreu um pequeno

aumento do delay, mas que não comprometeu o uso do EHWSNET, e que ocorreu um

ganho de modularidade com o uso do EHWSNET, melhorando a manutenabilidade do

código, diminuindo assim o esforço do programador em promovê-la. Fazendo com que

75

os objetivos secundários também fossem alcançados e respondendo o segundo e terceiro

questionamentos, respectivamente.

Para um exemplo de benefício no uso do EHWSNET pode-se tomar a falha relacionada

ao DNS: o compartilhamento NF-e/DETRAN já enfrentou problemas por falha ocorrida

no servidor DNS geral da rede do estado, que não estava conseguindo resolver o endereço

para o serviço web hospedado nos servidores da SET/RN e a exceção propagada era a

primeira mensagem para a falha Domain Name System Down apresentada na Tabela 8.

A causa da falha demorou a ser encontrada e, consequentemente, a resolução para a

mesma demorou a ser aplicada, gerando problemas para as concessionárias de veículos e

seus clientes pelo atraso na emissão dos documentos necessários para os novos veículos

adquiridos. Caso o EHWSNET já estivesse sendo utilizado, a causa da falha seria iden-

ti�cada, agilizando a resolução para a mesma, pois a exceção propagada seria a segunda

mensagem para a falha Domain Name System Down apresentada na Tabela 8.

Outro exemplo de benefício no uso do EHWSNET envolve a falha relacionada ao

Remote Host Unavailable: o compartilhamento de NF-e/DETRAN também já enfrentou

problemas pelo fato do ambiente da SET/RN ser clusterizado. Na hora do balanceamento

de carga algumas requisições com origem do DETRAN/RN ao chegar à rede da SET/RN

estavam sendo redirecionadas para servidores do cluster que não tinha rota completa com a

rede do DETRAN/RN. Algumas requisições da aplicação cliente respondiam normalmente

e outras requisições ocorriam timeout, deixando a aplicação intermitente e retornando

como exceção propagada a primeira mensagem para a falha Remote Host Unavailable

apresentada na Tabela 8.

A causa da falha também demorou a ser encontrada e novamente acarretou problemas

para os usuários do DETRAN/RN. Caso o EHWSNET já estivesse sendo utilizado, a causa

da falha seria identi�cada, agilizando a resolução para a mesma, pois a exceção propagada

seria a segunda mensagem para a falha Remote Host Unavailable apresentada na Tabela

8. A Figura 28 mostra o retorno da tela da aplicação web do compartilhamento da NF-e

com o DETRAN/RN após consulta da NF-e, com a mensagem da falha ocorrida após o

uso do EHWSNET.

76

Figura 28: Retorno da tela Consulta NF-e

77

6 Trabalhos Relacionados

Existem muitos trabalhos envolvendo aplicações, serviços web e tratamento de ex-

ceções. Porém, a maior parte desses é dedicada a técnicas sistemáticas de geração de

defeitos, ataques e técnicas de detecção de falhas para testes de perda de pacotes de rede

e corrupção de mensagens. Poucos trabalhos focam no comportamento e propagação das

exceções lançadas e no desempenho com relação a esses mecanismos.

Além do trabalho de (GORBENKO et al., 2008), alguns outros trabalhos relacionados

foram encontrados. Em (KOPP; LEYMANN; WUTKE, 2010), são exibidas as camadas neces-

sárias para se construir uma arquitetura de serviços web e como essas diferentes camadas

são mapeadas na arquitetura do aplicativo. Com esta descrição, são identi�cados os dife-

rentes tipos de falhas que podem ocorrer e como classi�cá-las de acordo com a camada

onde a falha ocorre, fornecendo uma visão geral de como elas são manipuladas e investiga

como as aplicações se relacionam com os tipos de falhas.

Em (LOOKER; MUNRO; XU, 2004), é analisada a con�abilidade dos serviços web, inje-

tando defeitos em mensagens, classi�cando-as em falhas físicas, falhas de software, falhas

de gerenciamento de recursos, falhas de comunicação e falhas do ciclo de vida. Tanto em

(KOPP; LEYMANN; WUTKE, 2010), como em (LOOKER; MUNRO; XU, 2004), não é reali-

zado um estudo experimental do desempenho das aplicações quando essas exceções são

geradas.

No trabalho apresentado por (CABRAL; MARQUES, 2007), é citado que apesar do trata-

mento de exceção ter sido uma signi�cativa melhora em relação a outros mecanismos que

lidam com exceções, ele está longe de ser perfeito e que o mesmo é seriamente limitado.

O trabalho consiste em mostrar como os programadores estão manuseando esses trata-

mentos e a metodologia utilizada foi baseada na análise de códigos fontes e do bytecode

responsáveis pelo tratamento/manipulação das exceções.

Foram analisadas aplicações nas plataformas Java e .NET. Os autores concluem que

os manipuladores de exceção não são especializados o su�ciente e, por isso, os programa-

78

dores não utilizam as exceções como um mecanismo para recuperação de erros e ressalta

a importância de se atacar esse problema para que se criem maneiras de guiar o desen-

volvimento de novos mecanismos de tratamentos de erros.

Ainda em (CABRAL; MARQUES, 2007), os autores defendem que esse problema ainda é

mais crítico no .NET do que no Java, visto que no .NET o programador não é obrigado a

declarar as exceções e no Java, na maioria dos casos, o programador é forçado a declará-las

e por consequência, forçado também a se preocupar com a robustez do software.

O trabalho abrangeu categorias de software como bibliotecas, aplicações stand-alone,

servidores e aplicações rodando em servidores, mas não analisou serviços web ou qualquer

outro software que trabalhasse com SOA. O trabalho chega a propor algumas métricas

para orientar o desenvolvimento de novos mecanismos e abordagens para o tratamento

de exceção e coloca o uso de AOP como uma boa alternativa para implementar esses

mecanismos. Apesar do trabalho ter analisado códigos fontes e bytecodes de aplicações,

não foram apresentados resultados de como essas aplicações se comportam quando são

executadas e passam por uma situação de falha.

Já em (LEITE; RUBIRA; CASTOR, 2011), é ressaltada a importância de se evoluir mais

no estudo do tratamento de exceções propagadas em SOA, só que o foco do trabalho

é para soluções que seguem o modelo de SCA (Service Component Architecture), outra

forma de implementação de SOA, além dos serviços web, que é baseada em modelos de

componentes para a implementação e composição dos serviços, como é o caso do WS-

BPEL (Web Service - Business Process Execution Language), uma das mais populares

linguagens para a criação de composição de serviços web, mas que não suporta tolerância

à falha (LEITE; RUBIRA; CASTOR, 2011).

O trabalho propõe um modelo de tratamento de exceção que foi implementado como

uma extensão do Apache Tuscany SCA e que para os desenvolvedores aplicarem o modelo

em suas soluções eles devem utilizar AOP. Os autores de (LEITE; RUBIRA; CASTOR, 2011)

também a�rmam que a manipulação de erros em SOA é complexa e que, por isso, ela

deve ser �exível e dinâmica durante a execução do serviço.

A Tabela 11 apresenta uma comparação entre os trabalhos relacionados em consonân-

cia com os requisitos de�nidos no presente trabalho.

79

Tabela 11: Comparação entre os trabalhos relacionados

Artigos Tem .NET Tem serviços web Tem AOP

(GORBENKO et al., 2008) - Sim -

(KOPP; LEYMANN; WUTKE, 2010) - Sim -

(LOOKER; MUNRO; XU, 2004) - Sim -

(CABRAL; MARQUES, 2007) Sim - Sim

(LEITE; RUBIRA; CASTOR, 2011) - Sim Sim

A análise dos trabalhos relacionados revela que nenhuma das propostas acima elen-

cadas se enquadra nos requisitos de�nidos no presente trabalho de forma integrada, prin-

cipalmente no que diz respeito em aplicar uma solução para o .NET. Essa con�rmação

serviu como motivação para a elaboração do presente trabalho para compartilhar o co-

nhecimento com outros trabalhos que busquem resolver o problema levantado na presente

pesquisa.

80

7 Conclusão

Esse trabalho teve como objetivo estender a pesquisa realizada em (GORBENKO et al.,

2008), o qual realizou os mesmos experimentos na linguagem Java e para dois toolkits

diferentes. O objetivo foi entender o quão efetivo são os mecanismos de propagação de

exceções para o provimento de robustez em soluções envolvendo serviços web que utilizam

a plataforma .NET e propor uma solução para melhorá-los. De acordo com a pesquisa

realizada, as seguintes conclusões foram encontradas:

• A conclusão dada em (GORBENKO et al., 2008), de que serviços web desenvolvidos

em plataformas diferentes comportam-se diferentemente em falhas semelhantes foi

con�rmada.

• Falhas relacionadas a problemas de rede ou de ligação com o serviço geram um

tempo de espera até que a exceção seja capturada superior à falhas de sistema ou

aplicação.

• As mensagens propagadas com as exceções na maioria dos casos não informam a

causa raiz da falha ocorrida, visto que apenas 29% das exceções propagadas iden-

ti�caram os defeitos injetados e que das 17 falhas simuladas, 12 não noti�caram a

causa raiz do defeito injetado (este total corresponde a 71% das falhas analisadas).

• Conhecendo as características da propagação da exceção de cada falha simulada

é possível melhorar o tratamento especializado de falhas em soluções envolvendo

serviços web, ajudando assim o trabalho do desenvolvedor no provimento de uma

solução robusta.

• O uso da solução EHWSNET, desenvolvida no presente trabalho para tratamento

de exceções no uso de serviços web na plataforma .NET, conseguiu melhorar os

mecanismos de propagação de exceções envolvendo serviços web, identi�cando as

falhas ocorridas que geraram exceções de acordo com a abordagem realizada no

presente trabalho, aumentando o percentual de identi�cação que antes era de 29%

81

para 65%, os outros 35% correspondem as falhas que não geraram exceção e que

por isso não entraram no escopo do EHWSNET.

• Publicação de artigo no SBCARS 2013.

7.1 Limitações

Como limitações para o presente trabalho se tem o escopo restrito às falhas exploradas

na abordagem, os testes restritos ao uso de serviços web com o WCF do .NET e a falta

de um ambiente controlado para a realização das simulações e dos testes.

7.2 Trabalhos Futuros

Como trabalhos futuros, é pretendido expandir o estudo para outras tecnologias, como

a REST (Representational State Transfer), por exemplo, que tem crescido recentemente,

bem como testar a abordagem e o EHWSNET com serviços web em outras aplicações e em

outras plataformas, como a Java. Também se é desejado expandir o escopo do EHWSNET

para outras falhas que não foram exploradas na abordagem e procurar sempre melhorar

o tratamento existente na solução para as falhas estudadas.

A semântica das exceções também é uma discussão importante que deve continuar a

ser explorada em trabalhos futuros, apesar da análise realizada já apresentar alguns indí-

cios sobre possíveis problemas, se faz necessário o estudo contínuo para o aprimoramento

da resolução desses problemas.

82

Referências

AVIZIENIS, A. et al. Basic concepts and taxonomy of dependable and securecomputing. IEEE Trans. Dependable Secur. Comput., IEEE Computer Society Press,Los Alamitos, CA, USA, v. 1, n. 1, p. 11�33, jan. 2004. ISSN 1545-5971. Disponível em:<http://dx.doi.org/10.1109/TDSC.2004.2>.

CABRAL, B.; MARQUES, P. Exception handling: A �eld study in java and .net. In:Proceedings of the 21st European Conference on Object-Oriented Programming. Berlin,Heidelberg: Springer-Verlag, 2007. (ECOOP'07), p. 151�175. ISBN 3-540-73588-7, 978-3-540-73588-5. Disponível em: <http://dl.acm.org/citation.cfm?id=2394758.2394770>.

CENTER, W. D. InternetGetConnectedState function (Windows). jan. 2014. Jan., 2014.Disponível em: <https://msdn.microsoft.com/en-us/library/windows/desktop/aa384702%28v=vs.85%29.aspx>. Acesso em Jan, 2014.

DNS, W. D. C. Método Dns.GetHostEntry. jan. 2014. Jan., 2014. Disponível em:<https://msdn.microsoft.com/pt-br/library/system.net.dns.gethostentry%28v=vs.100%29.aspx>. Acesso em Jan, 2014.

ENCAT. Projeto Nota Fiscal Eletrônica - Manual de Compartilhamento de Informaçõesentre Órgãos Públicos - Versão 1.02. [S.l.]: Portal NF-e, 2008.

GARCIA, A. F. et al. A comparative study of exception handling mechanisms forbuilding dependable object-oriented software. Journal of Systems and Software, Elsevier,v. 59, n. 6, p. 197�222, 2001.

GOODENOUGH, J. B. Exception handling: Issues and a proposed notation. Commun.ACM, ACM, New York, NY, USA, v. 18, n. 12, p. 683�696, dez. 1975. ISSN 0001-0782.Disponível em: <http://doi.acm.org/10.1145/361227.361230>.

GORBENKO, A. et al. Experimenting with exception propagation mechanisms inservice-oriented architecture. In: Proceedings of the 4th International Workshop onException Handling. New York, NY, USA: ACM, 2008. (WEH '08), p. 1�7. ISBN978-1-60558-229-0. Disponível em: <http://doi.acm.org/10.1145/1454268.1454269>.

HOSSAIN, M. S. Web service based software implemented fault injection. InformationTechnology Journal, v. 5, n. 1, p. 138�143, 2006.

KOPP, O.; LEYMANN, F.; WUTKE, D. Fault handling in the web service stack. In:Proceedings of ICSOC 2010. [S.l.]: Springer, 2010. p. 303�317.

LEE, P. A.; ANDERSON, T. Fault Tolerance: Principles and Practice (DependableComputing and Fault-Tolerant Systems). [S.l.]: Berlin; New York, 2nd edn, 1990.

83

LEITE, D.; RUBIRA, C.; CASTOR, F. Exception handling for service componentarchitectures. In: Dependable Computing (LADC), 2011 5th Latin-American Symposiumon. [S.l.: s.n.], 2011. p. 84�93.

LOOKER, N.; MUNRO, M.; XU, J. Simulating errors in web services. InternationalJournal of Simulation Systems, v. 5, n. 5, p. 29�37, 2004.

LOWY, J. Programming WCF Services Building SOAs with Windows CommunicationFoundation. [S.l.]: O'Reilly Media, 2007.

MARKS, E. A.; BELL, M. Service Oriented Architecture (SOA): A Planning andImplementation Guide for Business and Technology. [S.l.]: Wiley, 2006.

MSDN. What Is Windows Communication Foundation. jan. 2014. Jan., 2014. Disponívelem: <http://msdn.microsoft.com/en-us/library/ms731082%28v=vs.100%29.aspx>. Acesso em Jan, 2014.

PAPAZOGLOU, M. P. et al. Service-oriented computing: a research roadmap.International Journal of Cooperative Information Systems, v. 17, n. 2, p. 223�255, 2008.

SANTANNA, C. et al. On the reuseand maintenance of aspect-oriented software:an assessment framework. In: Proceedings XVII Brazilian Symposium on SoftwareEngineering. [S.l.: s.n.], 2003.

SCHULT, W. LOOM.NET. nov. 2014. Nov., 2014. Disponível em: <https://loom.codeplex.com/>. Acesso em Nov, 2014.

SEFAZ/PE. Projeto GNRE Online - Manual de Integração - Versão 1.8. [S.l.]: PortalGNRE, 2010.

SOCKET, W. D. C. Método Socket.Connect (String, Int32). jan. 2014. Jan., 2014.Disponível em: <https://msdn.microsoft.com/pt-br/library/d7ew360f%28v=vs.100%29.aspx>. Acesso em Jan, 2014.

W3TECHS. Usage statistics and market share of ASP.NET for websites. abr. 2013. Apr.,2013. Disponível em: <http://w3techs.com/technologies/details/pl-aspnet/all/all>. Acesso em Apr, 2013.

WITH, B. ASP.NET Usage Statistics. mar. 2013. Mar., 2013. Disponível em:<http://trends.builtwith.com/framework/ASP.NET>. Acesso em Mar, 2013.

Uma Abordagem para Avaliação e Tratamento de Exceções ... · a adoção de técnicas de veri...

Documents

Transcript of Uma Abordagem para Avaliação e Tratamento de Exceções ... · a adoção de técnicas de veri...