Rodando .Net no Mainframe

Este trabalho foi porte de um sistema completo de nota fiscal, o WebISS,  pela empresa Azuris em meados de 2012. O sistema WebISS é desenvolvido pela empresa WebFis e Megadata e é usado nos estados: AL, BA, ES, GO, MA, MG, MT, PI, RO, RJ, SC, SE, TO.  São mais de 93 cidades que usam o sistema WebISS.

Como o sistema rodava somente em servidores windows,  existia uma demanda por cidades que precisavam ter o sistema rodando em Linux. E o pedido do porte do sistema para ambiente linux em mainframe foi da empresa Megadata e WebFis, que possui grande parte de seus sistemas em ambiente mainframe.  Esse porte foi realizado  muito antes de se pensar que a Microsoft compraria a Xamarin, e de termos hoje o .NetCore. Hoje o .NetCore é uma mistura do .Net com o mono, o que facilita muito ter o sistema rodando em Linux.

Estamos publicando somente hoje este relatório na integra, pois foi um trabalho estratégico para a empresa. Recebemos a autorização das empresa para esta publicação e gostaríamos de agradecer a um dos sócios – Andre Ortega – que tornou possível este trabalho e também a publicação desse conteúdo. 

 

Interoperabilidade com .NET em ambiente Mainframe de Alessandro Binhara

Ambiente de Testes

Especificações das Máquinas

Foi estruturado um ambiente de teste com as seguintes configurações de servidores para os testes do WebISS na plataforma Mono. Sendo um servidor com Suse Linux e Windows Server instalado no laboratório da G6. E uma máquina virtual no Z10 rodando a mesma versão dos Suse Linux.

Considerações

A máquina AMD em questão é uma máquina de cinco anos atrás, um desktop. Considerando uma tecnologia ultrapassada frente a tecnologias de máquinas atuais como processadores XEON e I7 para servidores que atualmente rodando a aplicação do WebISS .

 

 

Configuração Mono – PC

Objetivo

O objetivo de realizar a instalação do Mono em plataforma PC é realizar teste do mono no ambiente Linux e no ambiente Windows. Rodando o WebISS e

Instalação Linux PC

A atividade iniciou instalando e configurando um Suse Linux 11 em uma máquina AMD comum, a estratégia para o teste do WebISS no Mono consistem em instalar  o Mono num ambiente conhecido, atualizar e compilar todos os pacotes usando a última versão do mono. Feito isso, configurar todo o ambiente do Apache para a execução do mono como o WebIss, fazer o deploy do WebIss e resolver todos os problemas de compatibilidades encontrados. Feito isso reproduzir a mesma instalação e configuração no Mainframe.

Donwload Suse Linux Enterprise

O Suse Linux Enterprise pode ser conseguido numa versão de avaliação no site WWW.suse.com. Podem ser encontradas as versões i586 e 64BITS. Além do Suse, é importante fazer o Donwload do Mono Tools Extension que é uma extensão do Suse que já traz o Mono pré-empacotado. Sem ele não será possível instalar os pacotes do mono para o suse. Outra opção que pode ser usada é a instalação do mono através dos repositórios do mono na internet, como pode ser visto a seguir.

Instalação Pacotes Pré Compilados

O Linux tem um sistema de empacotamento que é possível usar para instalar os aplicativos. Pacotes pré-compilados pode ser instalados destes repositórios.  O comando responsável por instalar pacotes e adicionar repositórios é o Zypper. O uso do Zypper é na verdade bem similar ao do apt-get, com parâmetros e opções similares. Se quiser ver detalhes sobre o pacote antes de instalar, use o “info”, como em:

 zypper repos

Os repositórios que aparecem na lista são os mesmos que aparecem ao acessar o “Software > Software Repositories” do YaST.

Você pode tanto adicionar novos repositórios através do YaST quanto adicioná-los diretamente via linha de comando. Nesse caso, usamos o comando “zypper addrepo”, Para adicionar o repositório do mono:

 zypper addrepo http://download.opensuse.org/repositories/Mono/SLE_11/i586/ mono

Lista todos os repositórios já definidos.

 zypper lr

Para instalar um pacote, use o “zypper install”, para instalar o mono segue a seguinte linha:

zypper in mono-complete

Como de praxe, ele calcula as dependências e exibe uma lista de outros pacotes que precisarão ser instalados, juntamente com o volume de arquivos que serão baixados e o espaço em disco que será usado. Para remover, use o “zypper remove”, como em:

zypper remove mono-complete

Em casos onde você não saiba o nome exato do pacote, ou ele apareça com um nome diferente do que você esperava, use o parâmetro “search” informando um trecho do nome para realizar uma busca, como em:

 zypper search yast

Para verificar se o mono está realmente instalado e em funcionamento bastar abrir um terminar e digitar #mono –version. Deverá ser apresentada a seguinte tela :

 

Instalaçãodo Mono apartir das fontes

Outra forma de instalar o Mono é a partir dos códigos fontes. Neste caso é necessários um processo de compilação do fonte. Esse processo é usando geralmente para desenvolvedores que precisa usar a versão em desenvolvimento do mono. Para compilar o Mono a partir dos fontes precisamos instalar os pacotes prontos ou fazer a instalação do bootstrap que é um conjunto mínimo dos executáveis necessários para a compilação do mono.

Download do Fonte do Mono

O fonte pode ser óbito na forma de pacotes tag.gz site do projeto em http://download.mono-project.com/sources/ ou a outra forma é baixando diretamente dos repositórios no gitHub em https://github.com/mono/mono basta clicar em download e escolher o formato que se deseja baixar .tar.gz ou .zip .  Para descompacta o pacote tar.gz usa-se :

 tar –zxvf nome.do.arquivo.tar.gz

Para realizar teste com a versão em desenvolvimento do momento. É melhor usar o git, ele deve ser instalado nos suse com adicionando o seguinte repositório a ser adicionado ao yast.

 zypper addrepo http://download.opensuse.org/repositories/devel:/tools:/scm/SLE_11_SP1/  Git

No caso do z10 talvez seja necessário compilar o GIT. Para evitar mais uma compilação é mais facil baixar o fonte na máquina local e enviar para o Z10. O comando para baixar o fonte do mono do GitHub:

 git clone https://github.com/mono/mono.git

Após essa operação cerca de 315MB de código fonte serão baixados, e poderá ser dando inicio ao processo de compilação.

Compilação do Mono

Para compilar o mono você ainda precisar instalar o automake e g++ com o comando. Para essa instalação será necessário que a mídia de DVD do Suse esteja montada.

 zypper in automake

 zypper install gcc-c++

 

Entre no diretório do mono e inicie a compilação com o comando :

 

 

Agora com a compilação do mono realizada será possível instalar os módulos do mono no Apache e realizar a configuração do ambiente Apache. Em alguns casos será necessários recompilar o apache e seus módulos incluindo o modMono.  Destaca-se as configurações do modMono que ficam no /etc/apache2/conf.d/mod_mono.conf

 

 

O particionamento desta máquina ficou distribuído de uma forma muito simples:

 

Instalação do Apache

Para instalar o apache, mas usar a ferramenta de instalação padrão do Suse o Yast e selecionar os pacotes do apache. No suse ja vem com os módulos do mono pré compilados para o apache. Basta seleciona-los e realizar a instalação.

Caso se use uma instalação do mono a partir dos fontes, será necessário recompilar os módulos juntamente com o Apache.

 

 

 

Configuração Mono – Z10

Objetivo

O objetivo desta atividade foi  configurar uma máquina virtual com Suse Linux Enterprise mainframe para testar o funcionamento do mono e do WebISS.

Preparação do Ambiente

O Suse linux Enterprise foi instalado pela Megadata, e devido a questões de segurança suas partições foram divididas em diversos volumes. Para um ambiente de produção em ambiente de servidores isso é altamente recomendável, segue abaixo o particionamento utilizando no Linux no Mainframe.

 

Considerando que este servidor não é um servidor de produção, mas um servidor que será usado para teste e compilação de pacotes do mono. A organização das partições não facilitou muito o trabalho, pois era necessário copiar código fonte de um lado para o outro. Sugere-se que caso seja necessário uma nova instalação de teste que sejam usadas no máximo 2 partições.

Com o servidor instalado e operacional foram iniciados os teste com o Z10 fazendo comparativos de desempenho, para verificar se não existia uma diferença muito grande de processamento entre as maquinas testadas, ou se seria necessário a criação de algum indexador para os testes.

 

 

Testes iniciais com Z10

A primeira coisa que precisamos é saber se o poder de processamento do mainframe na VM esta compatível com o PC que vamos usar para teste. Eles precisam ter uma poder de processamento parecido, senão nossos testes serão inúteis e precisamos de uma comprovação disso, fora do ambiente do mono ou de qualquer VM.  Não queremos testar o hardware e sim o software que vai rodar nele. A ideia é saber se o mainframe é mais rápido ou mais lento para executar o Mono/.net.

Bogomips

A primeira ideia que tivemos foi usar do Bogomips do kernel do Linux para saber se estão compatíveis. BOGOMIPS é uma combinação de Bogus e Mips. MIPS significa Milhões de Instruções por Segundo (Millions of Instructions per Second), ou Indicador sem importância de velocidade do Processador (Meaningless Indication of Processor Speed). O número que aparece na hora do boot é resultado de uma calibração de tempo do kernel, usado para curtíssimos atrasos de loops por alguns módulos de dispositivos.

Segundo De Lars Wirzenius: MIPS é a sigla para Milhões de Instruções por Segundo; ela é a medida para a velocidade da computação de um programa. Como a maioria destas medidas, ela é mais freqüentemente aumentada do que usada corretamente (é muito difícil comparar o MIPS para diferentes tipos de computadores). BOGOMIPS é uma invenção do Sr. Linus. O kernel (ou era um controlador de dispositivo?) precisa de um tempo de loop (o tempo também é uma sigla e/ou precisa ser exato para um método de espera de um loop sem uso), que deve ser calibrado para a velocidade do processador da máquina. Daí, o kernel mede na hora da inicialização quão rápido um certo tipo de loop roda em um computador. "Bogo" vem de "bogus", isto é, algo que é falso. Então, o valor do Bogomips fornece alguma indicação da velocidade do processador, mas é também um modo não muito exato para ser chamado de tudo menos Bogomips.

De acordo com o mini-HOWTO do BOGOMIPS, a velocidade de sua máquina deve ser:

Common BogoMips Ratings

Processor              BogoMips       Comparison

---------              --------       ----------

Intel 8088              clock * 0.004    0.02

Intel/AMD 386SX         clock * 0.14     0.8

Intel/AMD 386DX         clock * 0.18     1 (definition)

Motorola 68030          clock * 0.25     1.4

Cyrix/IBM 486           clock * 0.34     1.8

Intel Pentium           clock * 0.40     2.2

Na medição atual realizada temos:

  • Para o AMD Atholn 64 x2 dual Core Processor 4400+ : 4620.98 Bogomips
  • Para o IBM/S390: 1058bogomips

Calculo de PI

2) A segunda  ideia que eu tive é usar um código de C ou C++ compilado com gcc usando por exemplo um  algoritmo de calculo de PI , com varias casa decimais. Posso compilar para código nativo em cada máquina e cronometrar o tempo de execução. A ideia que eles sejam similares para sabermos que as máquinas estão compatíveis no poder de processamento.

Calculo de PI simples o fonte pode ser encontrado em  http://bellard.org/pi/pi.c

Para compilar no Windows instalar o Unix for service disponível no painel de controle do Windows. (http://suacommunity.com/sua.aspx) Para compilar com o gcc usar o seguinte comando:

# gcc –o pi.exe pi.c -lm

Código fonte do cálculo do PI usado está no apêndice deste documento.

Script para tomada de tempo no Linux :

 

Script para tomada de tempo no Windows. O comando time funciona um pouco diferente:

 

 

PI IBM/S390 AMD Athlon(tm) 64 X2 % AMD mais rápido
100 0,03 0,01 66,66667
1000 2,04 0,72 64,70588
10000 179,29 56,61 68,42546
100000 15931,09 4953,93 68,90401

 

 

 

 

Compactação de Arquivos

3) Outra ideia é usar um compactador tipo RAR .Os algoritmos de compressão são bons testes de performance são altamente randômicos ocupam boa memória usam bastante  processamento. Não tem cache que resista acabam testando o hardware diretamente. Quanto menos compressível o arquivo, melhor, pois o compressor vai se matar para tentar comprimir, passando por todos os passos do algoritmo, e não vai conseguir.

IBM/S390 AMD Athlon(tm) 64 X2 % AMD mais rápido
Compactação 16,43 9,8 40,35301

 

4) Uso do hdparm para testes. O hdparm é um utilitário muito usado, que permite ativar otimizações para o disco e medir velocidade. Não se trata necessariamente de um utilitário para "turbinar" o seu sistema, mas para descobrir e corrigir problemas de configuração do disco rígido que podem comprometer o desempenho.

Teste de escrita no Cache.  Teste com hdparm para verificar o IO e velocidade de disco
hdparm -T /dev/sda


AMD
Timing cached reads:   2026 MB in  2.00 seconds = 1013.09 MB/sec
Timing cached reads:   1962 MB in  2.00 seconds = 981.03 MB/sec
Timing cached reads:   2036 MB in  2.00 seconds = 1018.22 MB/sec
Timing cached reads:   2024 MB in  2.00 seconds = 1012.14 MB/sec
Timing cached reads:   2050 MB in  2.00 seconds = 1025.12 MB/sec
Timing cached reads:   2034 MB in  2.00 seconds = 1016.97 MB/sec
Z10
Timing cached reads:   468 MB in  2.01 seconds = 232.44 MB/sec
Timing cached reads:   6218 MB in  2.00 seconds = 3111.11 MB/sec
Timing cached reads:   6256 MB in  2.00 seconds = 3129.82 MB/sec
Timing cached reads:   6104 MB in  2.00 seconds = 3053.78 MB/sec
Timing cached reads:   6194 MB in  2.00 seconds = 3099.54 MB/sec
Timing cached reads:   6220 MB in  2.00 seconds = 3112.44 MB/sec

Teste de Escrita no Device hdparm -t /dev/dasda

Z10
webissh:~ # hdparm -t /dev/dasda
Timing buffered disk reads:  110 MB in  3.05 seconds =  36.05 MB/sec
Timing buffered disk reads:  168 MB in  3.00 seconds =  55.94 MB/sec
Timing buffered disk reads:  200 MB in  3.04 seconds =  65.79 MB/sec
Timing buffered disk reads:  218 MB in  3.06 seconds =  71.22 MB/sec
Timing buffered disk reads:  228 MB in  3.03 seconds =  75.20 MB/sec
Timing buffered disk reads:  232 MB in  3.01 seconds =  77.11 MB/secAMD
linux:/home/binhara/scriptZ10 # hdparm -t /dev/sda
Timing buffered disk reads:  304 MB in  3.00 seconds = 101.22 MB/sec
Timing buffered disk reads:  304 MB in  3.01 seconds = 101.13 MB/sec
Timing buffered disk reads:  300 MB in  3.00 seconds =  99.92 MB/sec
Timing buffered disk reads:  300 MB in  3.02 seconds =  99.44 MB/secTiming buffered disk reads:  298 MB in  3.01 seconds =  98.89 MB/sec
Timing buffered disk reads:  296 MB in  3.02 seconds =  98.14 MB/sec

 

 

Teste Ruby Destrossator

Esse script foi construído para o grupo Buscapé com o objetivo de gerar grandes volumes de dados aleatórios, para fazer teste de carga nos sistema de recomendação do grupo. As bases de dados são em arquivos texto e o ruby foi executado usando a máquina virtual java com Jruby.

O objetivo de roda o ruby no Java é garantir as escalabilidade, podendo usar múltiplos processadores gerando código nativo para as máquinas.

Executando no PC:

linux:/home/binhara # time ./jruby-1.6.4/bin/jruby destrossator_nowrite.rb

Finito (took 0.0 weeks, 0.0 days, 0.0 hours, 29.0 minutes, 17.1980000000001 seconds)

 

Executando no Z10:

webissh:/home/mono # time /root/jruby-1.6.4/bin/jruby destrossator_nowrite.rb

Finito (took 0.0 weeks, 0.0 days, 0.0 hours, 31.0 minutes, 25.5609999999999 seconds)

 

Podesse verificar que o tempo demandado foi similar em ambas as plataformas.

Instalação Linux Z10

Instalando Z10

Após a instalação do Linux no Z10 com sua versão especifica foram instalados as pacotes do Mono Extension. Mas se percebeu que a versão empacotada do mono era muito antiga e seria necessários recompilar o mono a partir dos fontes com uma versão mais atual.

Instalando Pacotes Mono Extension

SUSE Linux Enterprise Mono Extension, um framework de aplicações. NET, permite que as organizações para executar seus Microsoft. NET servidor baseado em Linux. Baseado em Mono-uma fonte aberta, multi-plataforma. Âmbito e aplicação NET executado em conjunto com o SUSE Linux Enterprise Server. Ele permite que as organizações de TI facilmente porta. NET aplicações baseadas no Windows para o Linux sem um grande investimento em reescrever código. Com esta oferta, os desenvolvedores corporativos e ISV podem desenvolver novo Linux e aplicações multi-plataforma usando. NET enquanto recebendo atualizações de produtos, segurança e correções de bugs e suporte premiado SUSE.

Confira esta avaliação gratuita do SUSE Linux Mono Extension Enterprise, que inclui todo o conteúdo da versão completa mais 60 dias de patches e atualizações (ou 180 dias para System z). Isso não inclui o acesso a qualquer suporte técnico ou para qualquer atualização de software para além do período de avaliação. Para obter suporte técnico e acesso anual para correções e atualizações.

A instalação do Mono Extension é necessária para se obter os pacotes de mono compilados para o Mainframe, sem eles é impossível fazer o bootStrap da máquina virtual e com isso iniciar o processo de atualização do Mono.

Atualização do Mono Apartir dos Fontes

A última versão do Mono portada e suportada pela Novell para o Mono no Mainframe é a versão 2.0. Uma versão muito antiga se comparada com a versão atual, desde a versão 2.0 foram lançadas oficialmente as versões 2.2, 2.4, 2.8, 2.10 e está em desenvolvimento a versão 2.11.

Realizamos o download do repositório do mono da versão 2.11 para fazer o processo de atualização do mono. Ao tentar compilar a versão 2.11 com a versão 2.0 do mono, obtivemos a mensagem que não era possível e que seria necessário usa no mínimo a versão 2.11.

 

 

Foi necessário compilar versão após versão até chegar até versão 2.8 que era a versão necessária para atualizar para o Mono 2.11. Mas existe um bug no JIT do Mono s390 que não permite a compilação do mono na versão 2.11. A solução que conseguimos elaborar foi compilar como o mono 2.8 apenas a máquina virtual 2.10, e só então foi compilado a máquina virtual do mono 2.11 para o Z10. As bibliotecas do mono 2.11 foram compiladas em plataforma baixa e copiadas para o mainframe resolvendo o problema da geração dos binários para a plataforma Z10.  Depois de realizado todo esse processo tem o mono 2.11 funcionando perfeitamente no ambiente Mainframe.

O código fonte do mono ocupa atualmente cerca de 300M bytes de espaço em disco. É uma quantidade de código fonte muito considerável certa de 8milhões de linhas de código. O processo de compilação cerca de 8% mais rápido que no AMD 64.

Após todo o processo de compilação ter sido executado e as bibliotecas compiladas no AMD terem sido copias para os locais adequados no Suse Linux é hora de testar e verificar se a VM e suas ferramentas estão funcionando adequadamente. Basta executar mono –version e teremos as informações de qual mono está funcionando.

Instalação e Configuração do Apache

Com o mono instalado fica tudo mais fácil. Ao tentar colocar o mono funcionando com o apache recebemos uma mensagem de erro que a versão do módulo mod_mono não era compatível. O problema que o módulo do mod_mono é vinculado ao apache. Como não existe suporte para esta versão do mono foi necessário recompilar o mod_mono. Mas para que ele funcione de forma adequada no Apache foi necessário recompilar o Apache também. Um processo bem trabalhoso, mas que funcionou bem no final.

Um dos grandes problemas que dificultaram o processo de instalação foi a falta de muitos pacotes compilados para o s390. A quantidade de pacotes de programas pronto para uso é muito pequena. Da mesma forma como precisamos compilar o Apache e o Mono, tivermos que compilar uma série de bibliotecas e programa necessários para o trabalho. Um exemplo que pode dar uma ideia da falta de pacotes, não existia um pacote do GIT pronto, uma ferramenta básica no processo de download do fonte do mono. Sem ela não poderíamos sequer baixar o código fonte do mono para iniciar os trabalhos. Essa falta de suporte gerou bastante trabalho que em outras plataformas seria trivial por já estar pronto.

Não conseguimos por exemplos compilar o FAST-CGI para testar em conjunto com o Apache e o mono. Ele apresentou uma serie de problemas de bibliotecas desatualizadas necessárias para a compilação. Com isso deixamos o mesmo de lado e não foi possível rodar o WebIss no Apache com FastGCI. Isso poderia ter um aumento significativo de performance do mono para prover aplicações web.

 

Compatibilidade do WebISS

Compatibilidade de Código

Atualmente o Mono suporta o código C# desenvolvido no WebISS, pois ele está escrito em .NET 2.0. O que precisa ser analisado como compatibilidade são bibliotecas externas ao .NET usadas no WebISS. O Mono é capaz de executar qualquer código .NET, mas não é capaz de executar código Windows. Para detectar códigos Windows em aplicações .NET o mono dispõem de uma ferramenta chamada Moma http://www.mono-project.com/MoMA

Está ferramenta é capaz de analisar os binários de uma aplicação em mostrar em que pontos de código existem uma chamada Windows. Essa ferramenta foi executada nos binários e nas bibliotecas do WEbISS e com isso foram mapeadas as possíveis incompatibilidades do WebIss.

Compatibilidade de Bibliotecas

Usando a ferramenta MoMa foi possível gerar um relatório de compatibilidade das bibliotecas. O relatório completo pode ser encontrado em RelatorioWebissCompatibilidadeDLL.html ou o resumo pode ser visto abaixo.

As bibliotetecas Nunit,obout_slideMenu,ThoughtWorks, e World são 100% compatíveis com o mono.

As bibliotecas iTexsharp, MagicAjax MScaptcha podem funcionar parcialmente pois não fazem chamadas ao Windows.

Já as bibliotecas relacionadas a relatórios não irão funcionar pois apresentam muitas chamadas a API do Windows e é necessários remove-las e substitui-las por uma biblioteca compatível.

Compilando o WebISS no Linux

Com o auxilio do mono Develop foi possível compilar o WebISS no Linux. Revemos todas as bibliotecas incompatíveis  e recebemos cerca de 40 Erros de compilação. Os erros erram gerados principalmente por erros de página de código.

Formulários com Erros

Como removemos o componente de relatórios tivemos que remover os formulários com scripts incompatíveis. Foi realizada a remoção do Formulários com Relatórios com o seguinte script:

  • aspx
  • aspx
  • aspx
  • aspx
  • aspx
  • aspx
  • cs
  • cs
  • cs

Formulários que contem MagicAjax

A Biblioteca magicAjax também se mostrou inconsistente e foi necessários remover os scripts ajax dos seguintes formulários:

  • aspx,
  • aspx,
  • aspx
  • aspx
  • aspx
  • aspx
  • aspx
  • aspx
  • aspx
  • aspx
  • aspx
  • aspx
  • aspx
  • aspx
  • aspx
  • aspx
  • aspx
  • aspx
  • aspx
  • aspx
  • aspx
  • aspx
  • aspx
  • aspx
  • aspx
  • aspx
  • aspx
  • aspx
  • aspx
  • aspx
  • aspx

⠀⠀

Compatibilidade do código Fonte WebIss

Foram encontradas algumas incompatibilidade no código fonte, mas todos os problemas foram resolvidos. As bibliotecas incompatíveis foram removidas, mas foi possível gerar uma nota eletrônica com os ajustes realizados.

Problemas de Acentuação no código Fonte

Trocar código fonte acentuado foram realizados cerca de 60 ajuste de nomes de variáveis e componentes que estavam acentuados. Uma possibilidade é fazer um script que faça esse ajuste.

cat arquivo | tr çãõáéíó caoaeio >arquivo.novo

Foram encontrados poucos erros de acentuação que tonaram incompatível com o sistema de arquivos do linux. Ao tentar mudar a página de código no VisualStudio não funcionou gerando outros problemas. Então os caracteres acentuados foram substituídos por caracteres sem acento. Com essas alterações o MonoDevelop passou a compilar os fontes sem maiores problemas.

Exemplos de problemas encontrados de acentuação de código.

edObservação

/home/binhara/svn.branch/FormInconsistenciasNFeI.aspx.cs(39,39): Error CS1056: Unexpected character �’ (CS1056) (DesWebServer)

/home/binhara/svn.branch/FormInconsistenciasNFeI.aspx.cs(102,102): Error CS1525: Unexpected symbol ,', expecting ;’ (CS1525) (DesWebServer)

/home/binhara/svn.branch/FormInconsistenciasNFeI.aspx.designer.cs(71,71): Error CS1056: Unexpected character �' (CS1056) (DesWebServer)

 

CarregaPainelCadastroAutorizações

/home/binhara/svn.branch/FormPessoaABRASF.aspx.cs(43,43): Error CS1056: Unexpected character �’ (CS1056) (DesWebServer)

/home/binhara/svn.branch/FormCancelamentoDocPago.aspx.cs(27,27): Error CS1056: Unexpected character �' (CS1056) (DesWebServer)

 

chkGerarCrédito

/home/binhara/svn.branch/FormCancelamentoDocPago.aspx.cs(28,28): Error CS0128: A local variable named dito’ is already defined in this scope (CS0128) (DesWebServer)

/home/binhara/svn.branch/FormCancelamentoDocPago.aspx.cs(28,28): Error CS0128: A local variable named dito' is already defined in this scope (CS0128) (DesWebServer)

/home/binhara/svn.branch/FormCancelamentoDocPago.aspx.cs(44,44): Error CS0136: A local variable named dito’ cannot be declared in this scope because it would give a different meaning to dito', which is already used in a child’ scope to denote something else (CS0136) (DesWebServer)

/home/binhara/svn.branch/FormCancelamentoDocPago.aspx.cs(38,38): Error CS1525: Unexpected symbol dito' (CS1525) (DesWebServer)

 

pnlIncluirLancCorreção

/home/binhara/svn.branch/FormSuspensaoReativacaoGuia.aspx.designer.cs(78,78): Error CS1056: Unexpected character �’ (CS1056) (DesWebServer)

/home/binhara/svn.branch/FormSuspensaoReativacaoGuia.aspx.designer.cs(81,81): Error CS1519: Unexpected symbol `;’ in class, struct, or interface member declaration (CS1519) (DesWebServer)

 

O resultado que ao executar o sistema algumas páginas apresentam erros de caracteres como na imagem abaixo.

Problema de Execução na camada de Persistência

Encontramos um problema de execução na camada de persistência no método PersisteObject. public DataTable ProcessSql. Esse método é bem importante no sistema, pois processa as requisições SQL que são enviadas para o banco. Ele foi construído de forma bem genérica para suportar qualquer comando SQL. No entanto, existem no C# comando específicos para cada tipo de comando SQL. O Mono por ter uma implementação diferente da Microsoft e seguir os padrões publicados pela Microsoft, não se comportou da mesma forma e emitiu uma mensagem de erro. Fizemos um ajuste no método usando as implementações específica e a aplicação funcionou corretamente.

 

Método original

  1.  

 

 

Alteração no método para funcionamento e compilação correta

  1.  

Componentes de Relatórios

Um componente muito importante no sistema WebIss é o gerador de notas fiscais em PDF. No caso do WebISS ele usa uma biblioteca externa para gerar as notas fiscais e outros documentos no formato de relatórios impressos.

O componente usando hoje utiliza a API do Windows e isso torna essa biblioteca incompatível com o mono. Como não se possui o código fonte dessa biblioteca, visto que é uma biblioteca de terceiro, não é possível fazer ajuste para tornar compatível com o MONO. O que se sugere neste caso é a troca por um componente opensource que seja 100% compatível com o mono.

Existe uma centena deles e alguns componentes de relatórios selecionados para o uso são:

 

 

Projeto RDL

O Projeto RDL fornece uma implementação de qualidade da especificação RDL. A DLL compacto está disponível para incorporar o escritor de relatório em suas próprias aplicações. Um controle. Net permite-lhe incorporar relatórios dentro de seu visual aplicações e permitir a impressão. Uma biblioteca ASP.NET permite que você use seus relatórios em suas aplicações web. Um designer WYSIWYG está disponível para os desenvolvedores e não desenvolvedores para criar relatórios. O Projeto RDL é escrito em C # e requer .Net 2. http://www.fyireporting.com/

Report Manager

Report Manager é um aplicativo de relatório (Designer Gerenciador de Relatórios) e também um conjunto de componentes para Delphi, Builder e Kylix, também suporta ambiente de desenvolvimento aceitar controles ActiveX (Visual Basic, Visual FoxPro, Visual Studio.Net qualquer linguagem …). C dinâmica biblioteca padrão com funções exportadas é fornecida para utilizar o motor com qualquer outra língua como o GNU C. http://reportman.sourceforge.net/

SharpReports

SharpDevelop Relatórios (SDR) é a fonte aberto. Transporte NET relatórios com SharpDevelop. SDR suporta Windows (WPF ou Windows Forms), bem como da Web (ASP.NET) aplicações graças à sua capacidade de usar impressoras ou saída diretamente para PDF. Bases de dados (não limitado ao SQL Server!), Bem como listas de objetos são suportados como fontes de dados.

http://sharpdevelopreports.net/default.aspx?AspxAutoDetectCookieSupport=1

 

 

Exemplo de código de geração de um relatório.

 

 

 

Considerações Sobre Compatibilidade

O Sistema WebIss não foi pensando para rodar sobre plataforma linux, mesmo assim, eles esta funcionando bem, com exceção dos relatórios.

Apenas com uma boa orientação técnica e usando componentes 100% .NET,  a própria evolução natural do WebIss poderá rodar no Linux 100% sem nenhum ajuste ou mudança no código.

O maior trabalho a ser realizado atualmente é a troca do componente de relatórios.

É visível a diferença de performance na WEB entre o AMD e o Z10 rodando a mesma versão.

 

 

Instalando o WebISS

Deploy do WEBIIS no Linux

O processo de deploy consiste em instalar o sistema WebIss no Linux. Para garantir a compatibilidade da aplicação com o mono a aplicação foi toda recompilada no MonoDevelop que é a IDE de desenvolvimento de aplicativos mono para linux.

Basicamente o MonoDevelop foi instalado no SuseLinux para compilar o WebISS. Foi copiada a solução completa do Visual Studio dentro do linux, e foi aberta a solução do Visual Studio no MonoDevelop sem nenhum problema de compatibilidade.

Ao compilar a solução foram alguns problemas que foram descritos na continuação desde documento. Com todos os problemas resolvidos for gerada os binários de de instalação do aplicativo.

Bastou copiar os arquivos binários no diretório do apache e automaticamente o modulo do mono reconheceu a aplicação e foi possível acessá-la na web pelo Apache.

Deploy do WEBIIS no Linux Z10

Para fazer o deploy no Z10 foi necessária a recompilação do apache com o módulo atualizado no modMono. Foi copiado os binários do WebIss gerados pelo MonoDevelop para o diretório do pache no Z10. A aplicação rodou com sucesso no Z10 como pode ser visto na imagem abaixo.

 

Não foi necessária nenhuma configuração especial no apache para a execução da aplicação.

Deploy dos  Web Services – DesWebService

WebService estão bem suportado no Mono. Não tivemos problemas para compilar ou fazer o deploy da web serviço no Apache. Eles não usam nenhuma biblioteca externa ou qualquer função não implementada no Mono. A seguir uma tela da web services rodando no mono com apache

 

Testes do WebISS

Planejamento dos testes

Serão criados teste para atuar e fazer medições em múltiplo níveis. A idéia é conseguir um isolamento de cada teste para que estes não fiquem sujeitos a interferências externas. A aplicação  WEBIss pode ser entendida em múltiplas camadas, que podem ser testadas de forma independente ou em conjunto.

Banco de Dados MONO ou .NET Camada de Persistência Lógica de Negócio ASP.NET WEB.Forms Servidor WEB REDE Cliente Web Browser

 

Banco de dados: É o servidor de banco de dados com suas tabelas podem ser o SQLServer ou DB2.

MONO ou .NET: É a máquina virtual que executa todo o aplicativo WEBIss dentro do sistema operacional. Em ambiente Windows é usada a VM CLR e no ambiente Linux é utilizado a VM Mono.

Camada de Persistência: É a camada que entende o banco e gera as consultas SQL que serão consumidas pela aplicação. Essa camada esconde os comandos SQL e entrega para a aplicação objetos projetos prontos que são usados diretamente. Está camada foi construída em C# pela benefix e permite que a aplicação possa trocar de banco facilmente.

Lógica de Negócio: Onde são encontradas as regras de funcionamento da aplicação.

Asp.Net Web.Forms: Componente da Microsoft responsável por gerar as telas HTML do sistema. É a interface do usuário propriamente dita.

Servidor WEB: Esse também é um componente a ser testado, pois a variação desse software ou a melhor o pior calibração desse software pode dar ganhos expressivos de performance. No caso será usando no Windows o IIS e no ambiente Linux serão testados o Apache e o Nigx.

Rede: é a camada que conecta o usuário ao servidor. Essa camada deverá ser isolada sempre que possível para evitar latência de rede.

Cliente Web Browser: São os navegadores Web, atualmente os diferentes engines de renderização tem causado grande impacto na percepção de velocidade das aplicações por parte dos usuários. É um componente a ser isolado nos teste também.

Testes unitários

Teste de unidade é toda a aplicação de teste nas assinaturas de entradas e saídas de um sistema, consiste em validar dados válidos e inválidos via I/O (entrada/saída) sendo aplicado por desenvolvedores ou analistas de teste. Uma unidade é a menor parte testável de um programa de computador. Em programação procedural, uma unidade pode ser uma função individual ou um procedimento. Idealmente, cada teste de unidade é independente dos demais, o que possibilita ao programador testar cada módulo isoladamente.

Tem essa visão em mente serão construídos testes da aplicação que possibilitem a medição do tempo de execução de forma automatizada sem a intervenção humana. Possibilitando executar os mesmo testes diversas vezes. A fim de comprovar a performance do sistema em ambientes diferentes, com o mínimo de esforço humano.

Construção Teste unitários de desempenho

Estes testes deverão testar diversas situações de forma isolada sendo elas:  Teste de acesso a banco SQL, Teste do Framework de Persistência, Teste da Lógica de negócio, Teste de Algoritmos Genéricos e Específico, Teste de Execução e uso de memória, Teste de partes Funcionais do sistema, Teste do Servidor Web, Teste de  Integração, Teste de Interface Web , Construção Teste unitários via Selenium com o WebISS.

Teste de acesso a banco SQL

Estes testes serão construídos para testas o acesso ao banco. Serão criadas duas Tabelas QUERY_TEST e TRASACTION_TEST com a seguinte estrutura:

BANCO TESTE

 

CREATE TABLE [dbo].[QUERY_TEST](

[ID] [decimal](18, 0) NULL,

[NAME] [varchar](8) NULL,

[STRING1] [varchar](1000) NULL,

[BIGDECIMAL1] [decimal](18, 0) NULL,

[BIGDECIMAL2] [decimal](18, 0) NULL,

[DATE1] [date] NULL,

[DATE2] [date] NULL

) ON [PRIMARY]

CREATE TABLE [dbo].[TRANSACTION_TEST](

[ID] [decimal](18, 0) NULL,

[NAME] [varchar](8) NULL,

[STRING1] [varchar](1000) NULL,

[BIGDECIMAL1] [decimal](18, 0) NULL,

[BIGDECIMAL2] [decimal](18, 0) NULL,

[DATE1] [date] NULL,

[DATE2] [date] NULL

) ON [PRIMARY]

 

 

 

1) Serão criados os objetos em memória, será executado o teste de consulta aos objetos em  memória com múltiplas threads (1 a 20 threads). Resultados para Consultas e Transações em memória para 10mil objetos:

Para 1 milhão de Objetos:

 

Teste de Algoritmos Genéricos

Foram executados alguns algoritmos genéricos para medir a performance da máquina virtual mono rodando nas duas plataformas de hardware em Linux e Windows. O teste consiste um número X de operações e é medido o tempo em milissegundos. Quanto menor o valor em milissegundos mais rápidos foi a operação. Foram feitos teste com manipulação de ArrayList, Strings, Soma de inteiros e ponto flutuante, exception e reflexão e recursão. Abaixo temos os números encontrados para a execução no ambiente Linux em AMD64, Linux em Z10 e Windows 2008 com .NET.  Foi utilizando sempre a mesma versão de Linux com a mesma versão de mono, no caso mono 2.11.

Plataforma /Algoritmos ArrayList StringBuilder Adição de Integer & Floating Exception Reflection e recursão
Mono Linux 452 768 5192 321 4684
Mono Z10 1038 1926 12164 543 9787
dotNet Windows 499 639 5194 3057 5865

Visualizando esses testes genéricos pode-se se perceber que o desempenho do mono em Intel esta similar a performance do .NET, mas pode-se ver que ele foi muito mais rápido que o .NET no lançamento de Exceptions isso se deve ao fato o tratamento de exceptions é mais simplificado no Mono, e não tem todas as checagens de CAS que tem no .NET. Outro ponto é que o mono se apresentou mais rápido que o .NET em reflection e recursão. Não encontramos nenhuma razão especial para essa situação esteja acontecendo. Pela conversa com os desenvolvedores do mono parece de dar pela eficiência da estrutura do Linux, como gerenciamento de processos do kernel e memória, sem ter todas as camadas que o Windows tem.

O Mono em Intel está com performance similar a do .NET. O Mono está mais rápido que o .NET em Exceptions pois o  tratamento de exceptions é mais simplificado no Mono, ele não tem todas as checagens do .NET.  O Mono está mais rápido que o .NET em reflection e recursão, tal eficiência se dá pela  estrutura do Linux ser mais eficiente que o Windows.  A performance do Mono no Z10 foi bem pior que o Mono no AMD. Tendo em vista que o Linux e o Mono  é o mesmo fonte utilizado. Tem-se um forte indício que a performance da aplicação na máquina Z10 é bem inferior que no AMD.

Algoritmo multi thread

Para evitar questionamento sobre o teste com aplicações single thread, e também a capacidade da máquina virtual do Mono em executar aplicativos multi-thread. Forma usando teste em multithread na máquina virtual java.

No teste inicial foram criados objetos simples em memória em centenas de milhares. E depois eram feitas consultas em memória e cronometrado o tempo de execução de cada tarefa. Para a quantidade de 1 milhão de objetos os sistema na média ficaram empatados. AMD=2.426.000  Z10= 2.434.000 com 8mil operações por segundo de diferença.

Na sequencia foram realizar teste de IO, escrevendo os objetos de memória no disco usando processo de serialização de objetos. Em seguida era feitas consultas, novamente para uma quantidade de 1 milhão de objetos.

No gráfico abaixo pode ser visto que o Z10 foi muito mais eficiente com IO .

 

Realizando um teste com consultas ao SQL SERVER. Tanto Z10 quando o AMD realizava consulta a um SQL Server em um servidor Windows. É visível o ganho em número de consultas usando o AMD. É interessante observar que com o aumento de número de threads paralelas o AMD teve um ganho de performance.

Considerando que a aplicação WebIss não fará uso de IO do mainframe, e o grande requisito do WebIss é processador, memória e acesso ao SQL Server.  A aplicação WebIss terá uma eficiência muito maior rodando em uma arquitetura AMD/Intel que no Z10.

Criação de Objetos em Memória

Depois dos teste com a máquina virtual java, foram iniciados os teste com C#. Usando .NET no windows e Mono no Linux (Z10 e AMD). Abaixo podem ser visto os resultados para criação de objetos em memória para volumes de 1mil, 10mil e 100mil objetos.

1mil objetos 10mil

objetos

100mil

objetos

Mono AMD 17 ms 115 ms 1059 ms
Mono Z10 25 ms 146 ms 1458 ms
.NET AMD 31 ms 93 ms 936 ms

 

Pode ser observado que quanto menor é melhor, pois levou menos tempo para criar os objetos em memoria. O C# rodando em plataforma Windows foi nitidamente mais rápido que no mono no linux, mesmo rodando no ambiente MainFrame

Teste SQL – 1 Thread .C#

No próximo teste foram criados 1mil objetos em memória, em seguida esses objetos foram salvos no banco de dados através de comandos SQL. Depois de criada a base de dados foram realizadas 1 mil buscas , 1 mil updates alterando os dados do bando de dados. A última etapa foi deletar os registros criados.

Criar Memória Insert Busca Update Delete
Mono AMD 17 8727 936 9472 11402
Mono Z10 25 4337 959 4379 4149
.NET AMD 31 10077 1029 9406 9592

 

O interessante deste teste foi que o Z10 com mono foi mais rápido que os demais na hora de inserir, atualizar e remover registro do banco. Mas a velocidade na busca dos objetos foi similar, isso comprova a superioridade do Z10 em manipulação de disco e IO pois essas operações gastam muito mais tempo de IO que processamento e memória. Já nas busca, o banco de dados se encarrega de trabalhar com esses mecanismos, sendo usado mais processamento e memória. Neste caso o resultado foi uma performance equivalente nas três plataformas.

A mesma situação se repte quando foram executados os testes para a quantidade de 10mil registros, como pode ser visto no gráfico logo abaixo.

 

Criar Memória Insert Busca Update Delete
Mono AMD 115 93232 26885 137954 131444
Mono Z10 146 43677 33916 94313 101117
.NET AMD 93 99637 29749 154284 153645

 

Testes dos WCF – Nota Eletrônica

Existe apenas um método não implementado no Mono. Mas este método é o método usado para autenticar as chaves digitais. Isso é um ponto vital para o funcionamento deste módulo do WebISS, sem ele esse módulo não funciona.

Opções são :

  • Implementar a funcionalidade o Mono. É um pouco desaconselhado pois será preciso uma pessoa altamente especializada, e é um recurso não disponível na equipa da WebISS. Mas é possível contratar sob demanda o que pode resolver o problema de compatibilidade.
  • Mudar a implementação da Aplicação WCF, pois existem diversos outros métodos no mono que fazem o trabalho de forma similar e já estão implementados e funcionando no mono. Essa pode ser uma solução simples e barata a ser implementada.
  • Outra opção é migrar o WCF para WebServices, pois o WebISS não é utilizada nenhuma característica especial do WFC . O WebISS não perderia nada em termos de funcionalidade e o processo de migração não seria complicado.

Observação:

Com a evolução rápida do mono e com o aumento do uso de aplicativos mobiles que é o atual foco do mono, este método será muito importante no uso em aplicativos mobiles. Conseguente é possível que nas próximas versões do Mono esse método esteja implementado. Deixando a camada de WFC 100% compatível com a atual versão do WebISS.

Considerações Finais

Resultados Encontrados

A principal questão deste trabalho era saber se era possível executar o WebISS no linux num Mainframe Z10. Foi comprovado que SIM, é possível executar o WebIss no Z10 usando a plataforma Mono com mínimo de esforço de programação e testes.

Outro item do trabalho foi avaliar o esforço necessários do porte do WebISS para o Z10. Isso foi realizado com sucesso executando algumas adaptações já descritas:

  • Troca do componente Ajax e Componentes de Relatórios.
  • Conversão do componente escrito em WCF para WebService.
  • Migração das Chaves de Criptografia do ISS para o Apache.

 

Foram também descritos os problemas encontrados e as possíveis soluções como:

  • Necessidade de uma maior conjunto de Testes: Criação de testes automáticos que garantirão o correto funcionamento em ambas as plataformas.

 

Avaliar desempenho do Z10 em relação a plataforma baixa como servidor de aplicação Web

  • O Z10 teve performance equivalente a um AMD de 5 anos atrás. Com certeza a aplicação não terá a mesma velocidade que tem usando a infraestrutura de processadores Xeon atuais.

 

Z10 não é tão performático como um INTEL/AMD para rodar uma aplicação Web como o WEBISS. Tudo que esta fora do ambiente do mainframe se torna lento, o Z10 não está preparado para esse tipo de situação. O Z10 não escala a aplicação sozinho, não possui nenhum mecanismo aparente para escalonamento da aplicação. A aplicação e o ambiente do sistema operacional precisam ser customizados para rodar nesse ambiente de forma a escalarem a quantidade de usuários.

 

Mesmo que seja migrado 100% o WebIss para o Z10 ele não terá a mesma performances que o atual ambiente de servidores windows. A única vantagem no uso do Z10 é seu tempo de disponibilidade, o que também é atingindo com a plataforma Windows hoje.

 

Muito provavelmente a aplicação no Z10 só terá ganho de performance sendo escrita de forma nativa para o z10. O mainframe não parece disponibilizar nenhum mecanismo de escalabilidade automática da aplicação. Seja Java ou C# , a aplicação deverá ter inerente a ela a escalabilidade para que novos servers possam ser criados para distribuir carga.

 

Tudo indica que será muito mais barato manter o sistema WebISS rodando em plataforma Windows que migrá-lo para Linux num MainFrame.

 

 

Código Fontes de Teste

Código fonte do Programa de Cálculo de PI

 

 

Código Fonte Ruby Destrossator

 

 

 

 

Códigos de Algoritimos Genéricos C#

 

 

Código Fonte Acesso Banco de Dados C# – Single Thread

 

 

 

 

Código Fonte Java de Escalabilidade

 

 

 

 

 

 

 

By | 2019-03-18T11:11:37+00:00 março 18th, 2019|Últmas Notícias, Xamarin|