Executavel em Servidor

[Complex]

Cumprimentos a todos,

eu estou neste momento a projectar um sofware de gestão (nada de extremamente ambicioso)
mas que preenche as minhas necessidades profissionais muito especificas.
Resumidamente trata-se de uma base de dados.
Agora que já tenho o modelo do que quero, estou a ponderar em que linguagem o devo fazer.

A minha primeira questão é a seguinte, se eu criar um .exe e o colocar num servidor é possivel
executar esse mesmo ficheiro em diversos terminais ao mesmo tempo, ou será melhor
colocar um exe em cada máquina que necessite e os dados no servidor?
Por esta altura já devem estar a pensar que em vez de pensar em exe's devia era pensar em
.asp ou qq coisa do genero (mas apesar da simplicidade, e de apenas necessitar de um browser, preferia nao ter de usar browser nenhum), mas gostaria de saber se isto é possivel, e em que linguagens o é.

A minha segunda questão seria como é que o fariam (que linguagem de programação).

Desde já quero agradecer a todos a vossa opinião.

 

[m00s]

hmmm, nao acredito que seja possivel executares um .exe a partir do servidor, isto sem teres comunicaçao com alguma parte no pc target...autorizada de algum* modo

os .exe tem de ser locais.

agora dependendo do que pretendes fazer podes ter outros modos à disposiçao.

 

[Complex]

hmmm, nao acredito que seja possivel executares um .exe a partir do servidor

O executavel está no servidor, e cada pc ligado à rede irá executar esse exe (isto se for possivel obviamente)

 

[napalm]

Claro que podes executar um processo concorrentemente.
Mas já agora só para te poder ajudar melhor, pq é que queres fazer o trabalho que já inúmeros SGBD realizam?

 

[Complex]

Obrigado pela resposta, napalm! Não eu não pretendo inventar a roda... A unica coisa que vou fazer é o interface e a estrutura do software, os reports e afins são feitos por SQL ou qq coisa afim...
Não sei se estás familiarizado com o Primavera ( e outros tantos do mesmo genero) o objectivo é ter uma coisa que será
semelhante mas para funções muito especificas (não as do Primavera), e para as quais o preço do software existente compensa que eu me esforce por desenvolver um software próprio...

 

[Armadillo]

Podes fazer das duas formas, mas aconselhava-te fortemente a teres o exe em cada posto devido a dependencias de dlls e afins que podem nao se encontrar no pc-cliente.

 

[mOrSa]

É possível, sim! Já vi isso feito... depende somente do OS! Afinal de contas, podemos ter instâncias da mesma aplicação com contas de utilizadores diferentes... depende somente do OS e do tipo de aplicação... Que seja correcto... depende do peso da interface gráfica e da maquina que vai suportar a carga...

1abraço

 

[Armadillo]

neste caso qo que mais me preocupa seriam as dependencias que o exe teria, se correr numa maquina "cliente".
a nivel grafico e de processamento é indiferente, porque o codigo é corrido pelo computador "cliente", apenas existe (va la) um upload do exe para o cliente.

 

[zxsat]

Desde que o programa "fale" o protocolo CGI tanto dá ser um .exe como um .bat
É claro que este tipo de programa não tem interface gráfica, apenas pode ter forms html.

Se tem mesmo que ser usado um .exe já existente então a única maneira é usar um qq. processo de acesso remoto ao desktop (do server), tipo Terminal Services ou VNC, existe pelo menos uma implementação dos terminais services que corre como um Active-X "dentro" de uma janela de IE, com VPN encriptada e tudo. Se o programa pode ser multi-user ou não depende de como é desenvolvido. Se usar recursos locais pode evidentemente haver conflitos, mas se for simplesmente um interface para enviar e receber informação para a base de dados então não há razões para não poder ser multi-user.

Evidentemente que se não está ainda nada desenvolvido então o melhor é everdar por uma solução mais normal com programação para web, algo mais normal do estilo de PHP, ou (deus nos livre) soluções M$.

 

[Armadillo]

eu optaria por uma aplicação exe cliente-servidor. pra mim seria mais simples de implementar (basta ter atençao e fazer os locks necessarios á bd para nao ocorrer erros graves).
Uar o terminal server é uma boa opção mas so tendo em atençao as capacidades do servidor e implementando regras "decentes" para os utilizadores.

 

[SL87]

A meu ver tens duas opções:
1ª Aplicação Web - É multi plataforma e n precisa de configurações do lado do cliente.

2ª Aplicação de Desktop - Permite ter uma base de dados local e no final do dia é enviada para o servidor principal, o que pode dar muitas dores de cabeça a ser implementado .
Tem a vantagem e poder ser utilizado em modo offline.
Também pode ser multiplataforma mas já da mais trabalho.

 

[Armadillo]

2ª Aplicação de Desktop - Permite ter uma base de dados local e no final do dia é enviada para o servidor principal, o que pode dar muitas dores de cabeça a ser implementado .
Tem a vantagem e poder ser utilizado em modo offline.

o que é isto???!???!?!?
é a 1ª vez que ouço tamanha barbaridade!!

Nao é assim que se faz uma app!!

 

[SL87]

o que é isto???!???!?!?
é a 1ª vez que ouço tamanha barbaridade!!

Nao é assim que se faz uma app!!

Então ilumina-nos com a tua sabedoria.....

 

[Armadillo]

tu tens consciencia do que disseste? acho que nao.
Caso real (mais banal do que tu julgas):
- BD:2GBytes de tamanho
- users app: 30
Agora imagina o que como seria todos os dias actualizar os dados. e todas as maquinas clientes terem essa bd. Mesmo que fosse usado um metodo semelhante a backups incrementais seria muito complicade manter a integridade dos dados... Para nao falar da qualidade de informação, que estaria sempre desactualizada 24horas.

O que se faz normalmente é assim:
Tens uma base de dados central e unica. Todos os clientes irao manipular dados dessa unica BD. A integridade de dados é efectuada com "locks" aquando das transacçoes (isto muito resumidamente)


[FONT=arial,helvetica] definiçao de Informação: é um conjunto de dados estruturados. A informação deve ser clara, precisa, rigorosa, atempada e concisa (quanto mais completa, melhor).[/FONT]

base de dados,
cliente-servidor e SGBD

 

[slack_guy]

é a 1ª vez que ouço tamanha barbaridade!!

Mas repara que ele disse:

que pode dar muitas dores de cabeça a ser implementado.

Só não tem razão quando diz que 'pode'. É que de certeza absoluta que vai dar muitas dores de cabeça de tanto bater com ela na parede e no final ficaria arrependido de ter começado :-)


EDIT:

preferia nao ter de usar browser nenhum

O que tu queres fazer está a cair em desuso.
Para aplicações cliente-servidor (com as características que apresentas), usa tecnologias Web: poupas tempo, dinheiro, recursos, neurónios, electricidade, petróleo, etc., etc., etc. Não re-introduzas problemas antigos de soluções 'arcaicas' em novas aplicações. Já bastam os problemas existentes com aplicações 'legacy', não empilhes mais problemas desses, sff.

 

[Armadillo]

Mas repara que ele disse:

Só não tem razão quando diz que 'pode'. É que de certeza absoluta que vai dar muitas dores de cabeça de tanto bater com ela na parede e no final ficaria arrependido de ter começado :-)

ta bem! é possivel trazer a lua pra terra. fisicamente é possivel. mas sugerias isso? acho que nao.
Aqui houve uma sugestao a fazer isso. Basicamente, criar um sistema desses é suicidio

 

[Injected]

1º é possivel executar um *.exe a partir do servidor sem haver problemas com dll's e afins...
2º a estrutura de dados pode ser em sql em que so precisas de uma base de dados com varias tabelas (os dados inseridos é da responsabilidade de cada utilizador) com que tenhas de programar o teu dito programa com um sistema de segurança de acesso)... Só precisas é de ter uma BOA MAQUINA (Terminal Server) para que toda a gente possa trabalhar...
3º podes utilizar essa mesma base de dados para implementares numa intranet ou internet como bem entenderes e dar-lhe a quase total funcionalidade como no programa que queres fazer...

 

[SoundSurfer]

A minha sugestão é fazeres uma aplicação que corre em cada desktop.

Quanto ao acesso a dados podes ter 2 opções:

- A Aplicação liga-se directamente à BD.
- Passar alguma da "lógica de negócio" para serviços (WebServices) que corram no servidor e façam eles o acesso a dados.

Quanto à linguagem: Java ou C# (.NET 2.0 ou 3.5 )

EDIT: Já agora, existem no mercado vários softwares (ERPs, + ou - complexos) que talvez colmatem as tuas necessidades à base de configurações e que podem compensar financeiramente o esforço que vais gastar.

 

[SL87]

é obvio que é muito dificil de implementar o sistema que referi.("Roma não se fez num dia")
Mas também não se sabe as necessidades do sistema.
Axo que Sybase implementou um sistema que permita usar dispositivos móvies para guardar infirmação e assim que tivessem conecção eram sincronozados com a BD principal. SQLAnywhere

Não se pode dizer se funciona ou s é exequivel, sem conhecer o sistema todo.
Cada caso é um caso e como tal existem muitas maneiras de fazer as coisas, axo que não tou a dar novidade nenhuma a ninguem....


E ja agora, quando falei no final do dia era um exemplo, apenas que dizer queria não era necessário ser um sistema sincrono.

 

[slack_guy]

é obvio que é muito dificil de implementar o sistema que referi

Não é uma questão de ser difícil ou fácil - isso não existe: o que é difícil para uns pode ser fácil para outros. Nem tão pouco é uma questão de ser possível ou impossível.

A questão é que, o que queres fazer podes fazê-lo de forma mais simples e mais acessível se usares tecnologias Web (browsers + linguagens cliente + linguagens servidor + SGBD).

Repara: o 'mundo' anda a correr no sentido de 'webizar' soluções e, parece-me, queres ir precisamente no sentido contrário (ambiente cliente-servidor com aplicações monoposto). A desvantagem clara é que quando acabares a aplicação, ficas com um sistema que já estava obsoleto quando o iniciaste. De resto, não tenho nada a ver com isso: a aplicação é tua, fazes como bem entenderes ;-)