Sim. Hoje eu já utilizo outra tecnologia voltada para aplicações Windows Service. Porém, pretendo ir migrando parcialmente para Java e por isso precisaria dele rodando como serviço pelo menos inicialmente. Após a migração total poderia colocá-lo em um servidor de aplicações por exemplo.
Além disso, tem a questão da proteção intelectual, pois um .class é facilmente descompilado e na minha estrutura atual o software é instalado no cliente, apesar de que meu software é registrado no INPI, ainda assim seria um transtorno enorme se ele fosse descompilado até devido a espionagem industrial.
Portanto, antes de iniciar a migração eu precisava resolver estas 2 questões: evitar ou dificultar ao máximo a descompilação e rodá-lo como serviço para que o usuário não precise logar no computador para rodar a aplicação.
Se futuramente vai ficar em um servidor sob administração dos proprietários da aplicação, a proteção aumenta. Local não tem jeito, Java não é a escolha certa, vão descompilar livremente, roubar a lógica, além de poder burlar partes do código. Uma opção é ofuscar o código, para dificultar o entendimento.
Por que não manter na tecnologia mais adequada para Windows Service e só implantar a versão em Java quando tiver o servidor?
ASP.NET Core é para web, então deverá estar assegurado no servidor (na nuvem ou na rede interna da empresa). Se não tem segurança no servidor, com .NET também vão descompilar facilmente para linguagem de alto nível. Se quer usar uma tecnologia que não tenha esse problema, vá de Golang, C++ ou até mesmo Delphi (ISAPI), que geram executáveis nativos.
Ahh sim, quanto ao front end Web eu entendo como funciona, porém estou me referindo ao backend de uma aplicação .NET criado em C#, é possível descompilar?