Alta disponibilidade e .NET

Esta página contém o artigo Alta disponibilidade e .NET Framework.

Introdução

Uma característica que permanece inalterada em aplicações industriais e de missão crítica é que a estabilidade operacional, segurança e proteção são seus principais requisitos. Mecanismos relacionados ao aumento da garantia de estabilidade estão entre as principais mudanças arquitetônicas possibilitadas por novas tecnologias, especificamente em software. O advento do Microsoft .NET Framework introduziu recursos mais altos e exclusivos para a criação de sistemas de alta disponibilidade.

Os recursos do .NET, incluindo ferramentas de produtividade, auxílios de desenvolvimento, bibliotecas de classes e padrões de comunicação, são cruciais para melhorar uma plataforma de desenvolvimento de projetos. No entanto, este artigo se concentra em duas áreas importantes que o .NET gerencia particularmente bem:

1. Criando uma arquitetura de software intrinsecamente segura

2. Gerenciando várias versões de sistemas operacionais, ferramentas de software e projetos

Segurança de software

Software intrinsecamente seguro

Na instrumentação de campo, a segurança é garantida por procedimentos internos ou garantias dos fabricantes e principalmente pela arquitetura do sistema, que utiliza tensões e correntes que são "intrinsecamente seguras" no ambiente onde a instrumentação irá operar. Isso garante que o sistema permaneça protegido mesmo em caso de falha específica do equipamento.

Quando começamos a usar o termo "software intrinsecamente seguro", recebemos muitas perguntas sobre seu significado no contexto do software. Refere-se à aplicação dos mesmos conceitos em hardware a sistemas de software. Especificamente, mesmo que um componente de software falhe, a arquitetura e o design do sistema devem ter proteção intrínseca para garantir a segurança e a integridade operacional.

A geração anterior de tecnologia dependia de C/C++, ponteiros e vários módulos compartilhando a mesma área de memória, com acesso direto aos recursos de hardware e sistema operacional. Embora esses métodos fossem necessários na época, eles são considerados intrinsecamente inseguros pelos padrões atuais.

Nova Geração x Geração Anterior

A nova geração de software utiliza ambientes computacionais como o .NET Framework, onde os processos são isolados nativamente uns dos outros e do sistema operacional, independentemente do programador. Essa abordagem permite uma melhor utilização de computadores com vários núcleos de processador. Ele garante maior estabilidade operacional, mesmo diante de possíveis erros ou falhas de driver e hardware em módulos individuais do sistema. Isso também se aplica a scripts de usuário em aplicativos.

As gerações anteriores dependiam de scripts proprietários ou linguagens interpretadas, como JavaScript, VBScript, VBA ou editores de expressão proprietários. A nova geração aproveita linguagens modernas e compiladas como C# e http://VB.NET, oferecendo controle sobre exceções, multi-threading, segurança aprimorada, orientação a objetos e melhor controle de execução.

As linguagens interpretadas não permitem a validação completa do código durante as fases de desenvolvimento. A validação ocorre apenas quando o código é executado, o que significa que muitos problemas são descobertos apenas durante a execução do projeto, não durante a configuração técnica. Um projeto típico pode ter centenas a milhares de caminhos de execução potenciais para o código, e o teste exaustivo de todos esses caminhos não é viável.

A capacidade de detectar possíveis erros durante a engenharia e de recuperar e isolar erros durante o tempo de execução é fundamental para a segurança e a estabilidade operacional. Esse nível de garantia só pode ser alcançado migrando scripts interpretados legados para linguagens compiladas e gerenciadas mais recentes.

Lançamentos e compatibilidade

Alta disponibilidade

Uma consideração importante em relação à alta disponibilidade é o gerenciamento de novas versões e o gerenciamento do ciclo de vida do sistema.

A maioria dos sistemas requer atualizações, correções e aprimoramentos após sua implantação inicial. Um dos fatores mais comuns que comprometem a disponibilidade de um sistema é o gerenciamento de mudanças. Mesmo que o aplicativo permaneça inalterado, a instalação de novos computadores, a atualização de sistemas operacionais e a aplicação de atualizações de ferramentas de software podem afetar a estabilidade do sistema.

Durante o desenvolvimento inicial de nossa plataforma, passamos muitos meses estudando como gerenciar melhor esse problema e como ambientes de programação virtualizados como .NET e Java poderiam ajudar a atingir esse objetivo. Por fim, descobrimos que começar com um design limpo permite incorporar componentes arquitetônicos que facilitam lançamentos e atualizações futuras, melhorando assim o gerenciamento de alterações do sistema e mantendo a alta disponibilidade.

Disponibilidade do sistema

A plataforma .NET provou ser uma estrutura de execução altamente eficaz devido a várias vantagens, incluindo suporte para várias linguagens de programação, integração mais fácil com componentes de servidor e cliente da Microsoft, ferramentas gráficas mais rápidas e avançadas e um ambiente de desenvolvimento altamente produtivo.

Aproveitando os recursos da plataforma .NET, este artigo explorará três técnicas para garantir o máximo de compatibilidade e disponibilidade do sistema, mesmo no caso de novas versões do .NET ou aplicativos que usam classes ou métodos preteridos. Essas técnicas são:

• Camada de aplicativo sobre o Microsoft .NET Framework.

• Compilador interno do Microsoft .NET com suporte a vários destinos.

• Aproveite a execução lado a lado.

O uso de tecnologias consolidadas, como bancos de dados SQL, para armazenar a programação e a configuração de aplicativos ajuda a manter a compatibilidade com versões anteriores à medida que o produto evolui. No entanto, este artigo explicará as três técnicas mais relevantes para novas versões do .NET e possíveis métodos preteridos.

Camada de aplicativo no .NET Framework

Camada de Aplicação Independente

O primeiro requisito de design é garantir que a ferramenta de software usada para criar o aplicativo esteja inteiramente em . NET. Por exemplo, nossa versão 2014.1 foi totalmente desenvolvida em C# usando o .NET Framework 4.0. O conceito envolve o uso da ferramenta de software para criar projetos de aplicativos finais, expondo a maioria das funcionalidades não como chamadas de plataforma de baixo nível, mas como uma "Camada de Aplicativo Independente". Vamos explorar e entender esse conceito.

Exceto para scripts de usuário que podem incluir chamadas diretas do .NET — discutidas na próxima seção — o restante da funcionalidade da ferramenta de software foi projetado para evitar a exposição do .NET diretamente ao usuário de engenharia. Em vez disso, ele apresenta uma ferramenta de configuração de nível superior.

Considere exibições, desenhos e animações em nossa plataforma. Em vez de exigir que os engenheiros de aplicativos se aprofundem na programação do .NET, a plataforma fornece uma interface de nível superior para habilitar propriedades dinâmicas por meio de diálogos e implantação interna desses recursos. Os usuários interagem com ferramentas de desenho e animação de alto nível em vez de lidar com programação WPF, XAML ou .NET.

Assim, quando uma classe interna do .NET é alterada, o software pode manter as mesmas configurações do usuário, mas implementar internamente o recurso usando as novas classes do .NET. Essa abordagem nos permite criar desenhos de exibição que são executados nativamente no Microsoft .NET WPF e no Apple iOS Cocoa.

Exemplo

Vamos usar o exemplo do "efeito Bevel Bitmap", obsoleto na versão 4.0, para ilustrar esse conceito. Suponha que seu aplicativo estava usando esse efeito.

De acordo com o conceito, em vez de implementar o efeito Bevel diretamente no código de programação do usuário, você teria uma "caixa de seleção de configuração para habilitar o Bevel dynamic" disponível em sua interface "DYNAMICS" - semelhante ao "SHINE - Outer Glow effect". O usuário selecionaria essa animação para um objeto e a ferramenta de configuração de software lidaria com a implementação internamente.

Quando o método Bevel for removido do .NET Framework, o pacote de software substituirá a implementação preterida por outro método ou biblioteca que imite o mesmo efeito visual o mais próximo possível, mesmo que a implantação interna seja diferente.

Essa abordagem garante que a experiência do usuário permaneça consistente, apesar das mudanças na tecnologia subjacente. O mesmo conceito se aplica a outros problemas potenciais. Ter uma camada de abstração entre o desenvolvimento do projeto e a plataforma permite manter a compatibilidade do projeto e gerenciar as alterações necessárias internamente. Isso possibilita manter a configuração do projeto compatível com versões futuras do .NET de uma forma transparente para os engenheiros de aplicativos.

Multi-Segmentação

Geração de código e classes de compilação

Outra vantagem significativa da plataforma .NET é seu suporte para geração de código e classes de compilação, o que permite incorporar um compilador .NET completo em uma ferramenta de Configuração de Projeto. Esse recurso fornece controle completo sobre como o sistema analisa e compila scripts criados pelo usuário, incluindo a opção de compilar o código para diferentes versões do Microsoft .NET Framework.

Por padrão, o sistema compila scripts de aplicativo para corresponder à versão do .NET usada pela ferramenta de software mais recente, executando-os em seu próprio AppDomain. No entanto, esse controle permite que o sistema compile scripts para uma versão anterior do .NET Framework, se necessário.

Independência do sistema operacional

Com o .NET 8, você pode executar o mesmo código em computadores Linux, macOS e Windows. 

Exemplo

Vamos explorar um cenário de caso: imagine que você tenha um sistema criado no Microsoft .NET versão 4.0 e precise migrá-lo para um novo .NET versão 4.X. Para esta discussão, vamos supor que o aplicativo que você criou tenha scripts usando métodos que foram preteridos no .NET Framework atualizado. E agora?

Existem duas soluções para isso:

• Solução A— Se o método obsoleto foi substituído por um semelhante que é suficiente para ser substituído automaticamente, a ferramenta de configuração do projeto pode ter um utilitário de atualização que localiza esses métodos no código e os substitui pelos novos automaticamente.

• Solução B — A ferramenta de configuração do projeto pode permitir que os usuários selecionem o .NET TARGET dos scripts do projeto. Assim como o Visual Studio pode criar DLLs para .NET 2.0, 3.5, 4.0 ou 4.5 com base na seleção do usuário, o compilador .NET inserido na ferramenta de Desenvolvimento de Projetos pode usar recursos semelhantes. Portanto, se necessário, podemos habilitar seu projeto para compilar os scripts em ambas as versões distintas do .NET, mesmo usando a ferramenta de configuração de software mais recente, de acordo com a seleção do TARGET pelo usuário. É possível ter o mesmo projeto rodando lado a lado com algumas tarefas de script na versão 4.0 e outras na versão 4.X, como veremos na próxima seção.

Execução lado a lado 

Várias versões

Por fim, o .NET tem um recurso potencial que deve ser aproveitado em um design de plataforma de desenvolvimento de projeto: ele pode executar diferentes versões do mesmo componente simultaneamente ou ter vários processos usando diferentes versões do .NET Action.NET em execução simultaneamente.

.NET Framework

Para mais detalhes, consulte o Execução lado a lado no .NET Framework artigo da Microsoft.

Por exemplo, usando os componentes principais incluídos nos serviços de gerenciamento de projetos e interface do usuário de nossa plataforma, diferentes versões do produto podem ser executadas simultaneamente no mesmo computador. Além disso, ao executar um projeto, os vários módulos, bancos de dados em tempo real, scripts e componentes de comunicação não são executados nos mesmos processos do Windows; eles são isolados em seus processos, trocando dados por meio de uma conexão WCF (Windows Communication Foundation).

Da mesma forma, a comunicação do dispositivo cria um processo separado do Windows (um .NET AppDomain) para cada protocolo, que também pode ser aplicado a diferentes scripts de usuário no projeto, um compilado e em execução para o .NET 4.0 e outro para outras versões. Ambos os processos são executados lado a lado, sem conflito, cada um em seu domínio, e ambos acessam tags em tempo real no processo do servidor.

32 e 64 bits

Outro cenário semelhante é o recurso que nos permite gerenciar a execução de 32 bits e 64 bits dentro da mesma configuração de projeto.

Por padrão, quando instalado em computadores de 64 bits, um aplicativo .NET aproveitará a plataforma do sistema operacional e executará todos os seus módulos nativamente no modo de 64 bits quando instalado em sistemas operacionais de 64 bits.

No entanto, às vezes, pode ser necessário forçar um script específico, driver de comunicação ou até mesmo as exibições gráficas do usuário a serem executadas no modo de 32 bits.

Por exemplo, se você estiver usando uma DLL de código externo ou um componente gráfico de terceiros que funciona apenas no modo de 32 bits, fornecemos uma versão RunModule32.exe para permitir que esse componente específico do projeto, como scripts, exibições ou comunicação de dispositivo, seja executado em um processo de 32 bits. Em contraste, o restante do aplicativo é executado no modo de 64 bits. A comunicação entre esses processos utiliza o WCF, garantindo o isolamento completo entre os processos.

Aplicação confiável

É crucial criar um aplicativo confiável que seja gerenciável durante todo o seu ciclo de vida. Esse é um dos principais benefícios de usar o .NET para criar novas ferramentas de software do zero, em vez de migrar o código anterior. Projetar um pacote de configuração de projeto para aproveitar as tecnologias atualmente disponíveis é essencial.

Apesar dos avanços tecnológicos, muitos sistemas ainda dependem do código portado do DOS ou usam APIs de baixo nível do Windows e versões mais antigas, o que pode levar ao efeito DLL-hell no Windows. Essa situação ocorre quando atualizações, instalações de software não relacionado ou alterações em qualquer parte do sistema podem quebrar tudo.

Utilizando os recursos certos fornecidos pelo .NET Framework e bancos de dados SQL e incorporando uma "Camada de Aplicativo Independente" bem projetada, você pode criar sistemas que mantêm alta compatibilidade com aplicativos anteriores enquanto continuam a evoluir em recursos e tecnologia.