This page contains the article High Availability and Esta página contém o artigo Alta disponibilidade e .NET Framework.
Introduction
One feature that remains unchanged in mission-critical and industrial applications is that operational stability, safety, and security are its principal requirements. Mechanisms related to increasing stability guarantee are among the core architectural changes made possible by new technologies, specifically in software. The advent of the Microsoft .NET Framework introduced higher and unique features for creating high-availability systems.
.NET features, including productivity tools, development aids, class libraries, and communication standards, are crucial in improving a Project Development Platform. However, this article focuses on two important areas that .NET manages particularly well:
Creating Intrinsically Safe Software Architecture
Managing Multiple Versions of Operating Systems, Software Tools, and Projects
Software Safety
Intrinsically Safe Software
In field instrumentation, security is guaranteed by internal procedures or manufacturers' warranties and primarily by the system architecture, which uses voltages and currents that are "intrinsically safe" in the environment where the instrumentation will operate. This ensures that the system remains protected even in the event of specific equipment failure.
When we began using the term "intrinsically safe software," we received many questions about its meaning in the software context. It refers to applying the same concepts in hardware to software systems. Specifically, even if a software component fails, the system architecture and design should have intrinsic protection to ensure safety and operational integrity.
The previous generation of technology relied on C/C++, pointers, and several modules sharing the same memory area, with direct access to hardware and operating system resources. While these methods were necessary at the time, they are considered intrinsically unsafe by today's standards.
New Generation x Previous Generation
The new generation of software utilizes computational environments such as the .NET Framework, where processes are natively isolated from each other and the operating system, regardless of the programmer. This approach allows for better utilization of computers with multiple processor cores. It ensures higher operational stability, even in the face of potential driver and hardware errors or failures in individual system modules. This also applies to user scripting within applications.
Previous generations relied on proprietary scripts or interpreted languages, such as JavaScript, VBScript, VBA, or proprietary expression editors. The new generation leverages modern, compiled languages like C# and http://VB.NET, offering control over exceptions, multi-threading, enhanced security, object orientation, and better execution control.
Interpreted languages do not allow for full code validation during the development phases. Validation occurs only when the code is executed, meaning many issues are discovered only during project execution, not during technical configuration. A typical project may have hundreds to thousands of potential execution paths for the code, and exhaustive testing of all these paths is not feasible.
The ability to detect potential errors during engineering and to recover and isolate errors during runtime is critical for safety and operational stability. This level of assurance is achievable only by migrating legacy interpreted scripts to newer compiled and managed languages.
Releases and Compatibility
High Availability
An important consideration regarding high availability is managing new releases and system life-cycle management.
Most systems require updates, corrections, and enhancements after their initial deployment. One of the most common factors that jeopardize a system's availability is change management. Even if the application remains unchanged, installing new computers, updating operating systems, and applying software tool updates can affect system stability.
During the initial development of our platform, we spent many months studying how to manage this issue better and how virtualized programming environments like .NET and Java could assist in achieving this goal. Ultimately, we discovered that starting from a clean design allows for embedding architectural components that facilitate future releases and updates, thus improving the management of system changes and maintaining high availability.
System Availability
The .NET platform has proven to be a highly effective execution framework due to several advantages, including support for multiple programming languages, easier integration with Microsoft server and client components, faster and more advanced graphical tools, and a highly productive development environment.
Leveraging the features of the .NET platform, this article will explore three techniques to ensure maximum compatibility and system availability, even in the event of new releases of .NET or applications using deprecated classes or methods. These techniques are:
Application layer on top of Microsoft .NET Framework.
Built-in Microsoft .NET compiler supporting multi-targeting.
Leverage side-by-side execution.
Using consolidated technologies, such as SQL databases, to store application programming and configuration helps maintain backward compatibility as the product evolves. However, this article will explain the three techniques most relevant to new .NET versions and potential deprecated methods.
Application Layer on .NET Framework
Independent Application Layer
The first design requirement is to ensure that the software tool used to create the application is entirely in .NET-managed code. For instance, our version 2014.1 was fully developed in C# using .NET Framework 4.0. The concept involves using the software tool to create final application projects, exposing most functionality not as low-level platform calls but as an "Independent Application Layer." Let us explore and understand this concept.
Except for user scripts that may include direct .NET calls—discussed in the next section—the remainder of the software tool’s functionality is designed to avoid exposing .NET directly to the engineering user. Instead, it presents a higher-level configuration tool.
Consider displays, drawings, and animations in our platform. Instead of requiring application engineers to delve into .NET programming, the platform provides a higher-level interface for enabling dynamic properties through dialogues and internal deployment of those features. Users interact with high-level drawing and animation tools rather than dealing with WPF, XAML, or .NET programming.
Thus, when an internal .NET class is changed, the software can maintain the same user settings but internally implement the feature using the new .NET classes. This approach allows us to create display drawings that run natively on both Microsoft .NET WPF and Apple iOS Cocoa.
Example
Let us use the example of the "Bevel Bitmap effect," deprecated in version 4.0, to illustrate this concept. Assume your application was using this effect.
According to the concept, rather than implementing the Bevel effect directly in user programming code, you would have a "Configuration checkbox to enable Bevel dynamic" available in your "DYNAMICS" interface—similar to the "SHINE - Outer Glow effect." The user would select this animation for an object, and the software configuration tool would handle the implementation internally.
When the Bevel method is removed from the .NET Framework, the software package will replace the deprecated implementation with another method or library that mimics the same visual effect as closely as possible, even though the internal deployment differs.
This approach ensures that the user experience remains consistent despite changes in the underlying technology. The same concept applies to other potential issues. Having an abstraction layer between your project development and the platform allows you to maintain project compatibility and manage necessary changes internally. This makes it possible to keep the project configuration compatible with future .NET releases in a way that is transparent to application engineers.
Multi-Targeting
Code Generation and Compiling Classes
Another significant advantage of the .NET platform is its support for code generation and compiling classes, which allows embedding a full .NET compiler within a Project Configuration tool. This capability provides complete control over how the system parses and compiles user-created scripts, including the option to compile the code for different versions of the Microsoft .NET Framework.
By default, the system compiles application scripts to match the .NET version used by the latest software tool, running them within their own AppDomain. However, this control allows the system to compile scripts to an earlier .NET Framework version if necessary.
Operating System Independence
With .NET 8, you can run the same code on Linux, macOS, and Windows computers.
Example
Let us explore a case scenario: imagine that you have a system created in Microsoft .NET version 4.0 and need to migrate it to a new .NET release 4.X. For this discussion, let us assume the application you created had scripts using methods that were deprecated in the updated .NET Framework. What now?
There are two solutions for this:
Solution A—If the deprecated method was replaced by a similar one that is enough to be replaced automatically, the Project Configuration tool may have an Upgrade Utility that locates those methods in the code and replaces them with the new ones automatically.
...
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:
Criando uma arquitetura de software intrinsecamente segura
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 , or ou 4.5 based on user selection, the embedded .NET compiler within the Project Development tool can use similar features. Therefore, if necessary, we can enable your project to compile the scripts in both distinct .NET versions, even when using the latest software configuration tool, according to the user's selection of the TARGET. It is possible to have the same project running side-by-side with some script tasks under 4.0 and others under 4.X, as we will see in the next section.
Side-by-Side Execution
Multiple Versions
Finally, .NET has a potential feature that must be leveraged in a Project Development Platform design: it can run different versions of the same component simultaneously or have multiple processes using different versions of the .NET Action.NET running concurrently.
.NET Framework
For more details, check the Side-by-Side Execution in the .NET Framework article by Microsoft.
For example, using the core components included in our platform's project management and user interface services, different versions of the product can run concurrently on the same computer. Furthermore, when running one project, the various modules, real-time databases, scripts, and communication components do not run in the same Windows processes; they are isolated in their processes, exchanging data via a WCF (Windows Communication Foundation) connection.
Similarly, device communication creates a separate Windows Process (one .NET AppDomain) for each protocol, which can also apply to different user scripts in the project—one compiled and running for .NET 4.0 and another for other releases. Both processes run side-by-side, with no conflict, each in its domain, and both access real-time tags on the server process.
32 and 64-bit
Another similar scenario is the feature that allows us to manage 32-bit and 64-bit execution within the same project configuration.
By default, when installed on 64-bit computers, a .NET application will leverage the operating system platform and run all its modules natively in 64-bit mode when installed on 64-bit operating systems.
However, sometimes, you may need to force a specific script, communication driver, or even the graphical user displays to run in 32-bit mode.
For instance, if you are using an external code DLL or a graphical component from a third party that only works in 32-bit mode, we provide a RunModule32.exe version to allow that specific project component—such as scripts, displays or device communication—to run in a 32-bit process. In contrast, the rest of the application runs in 64-bit mode. The communication between these processes uses WCF, ensuring complete isolation among the processes.
Reliable Application
It is crucial to create a reliable application that is manageable throughout its lifecycle. This is one of the top benefits of using .NET to build new software tools from the ground up rather than migrating previous code. Designing a Project Configuration package to leverage currently available technologies is essential.
Despite technological advancements, many systems still rely on code ported from DOS or use Windows low-level APIs and older versions, which can lead to the DLL-hell effect in Windows. This situation occurs when updates, installations of unrelated software, or changes in any part of the system can break everything.
...
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.