Ejecutar Remotamente

[kinobi]

Hola,

Empezado por diegofhernando

Sinceramente pienso que se ha dado solucion al problema

Entiendo que quieres decir que "no se ha dado solución al problema". En cualquier caso, yo creo que sí se ha dado solución al problema correctamente, ya que lo que quiere el compañero es hacerlo sin tener un proceso ejecutándose en segundo plano, estando éste "a la escucha" de peticiones de los clientes, y eso, evidentemente, no es posible.

Empezado por diegofhernando

y sin ofender,

por supuesto.

Empezado por diegofhernando

se trata de dar solucioes con codigo DELPHI,

No estoy de acuerdo.

1. Estos foros no son un servicio técnico gratuito y por tanto "no se trata de dar soluciones", en todo caso se trata de debatir soluciones como uno buenamente pueda y sepa. Otro asunto es que estas sirvan en todos los casos o que realmente exista una solución para el problema planteado.

2. Unas veces podrá ser con código Delphi y otras no. Es cierto que es un foro centrado fundamentalmente en Delphi, pero no exclusivamente.

Empezado por diegofhernando

mi aporte es que puedes instalar un programa en cada estacion cliente que se inicie con su sistema operativo, y cuando quieras hacer la ejecucion de tu programa envias una cadena que especifique la orden a las estaciones,

Vamos, lo que le hemos aconsejado las otras tres personas que hemos participado en el hilo.

Saludos.

[jachguate]

Has de tener en cuenta que lo sugerido por diegofhernando, así nada mas como está, constituye un grave problema de seguridad en los equipos de tu red, pues estas abriendo una inmensa puerta trasera por la que cualquier "cosa" puede entrar a las máquinas... si alguien la encuentra... luego no te quejes de lo que pueda ocurrir..

Se me ocurre:

ManijaPuertaTrasera.exe 192.168.0.42 "format d: /y"

owch!

Si es un solo programa el que queres bajar... podes poner ese mismo programa a la escucha en un puerto en partícular.... y al recibir una señal X, cerrarse. Incluso se me ocurre que podes hacer niveles de "urgencia" de la salida:

confirm
immediate

de manera que en confirm, se solicite al usuario que grabe su información y salga, y en immediate, simplemente salga.

Esto puede mejorar el nivel de "cariño" que los usuarios de la aplicación te van a tener...

Hasta luego.

[uhilari]

Hola a Todos

A ver, me van a disculpar todos pero creo que estan en un ERROR ROTUNDO

Empezado por kinobi

lo que quiere el compañero es hacerlo sin tener un proceso ejecutándose en segundo plano, estando éste "a la escucha" de peticiones de los clientes, y eso, evidentemente, no es posible.

Esto definitivamente es Falso, en la actualidad existen los famosos Sistemas Distribuidos los cuales se caracterizan por mantener partes del programa en diferentes PCs y comunicarse entre ellas (pueden ser archivos exe o dll), esto permite tener aplicaciones que estan -por asi decirlo- Durmiendo y que esperan una orden para Despertar. Esta manera de programación ya ha sido vista antes.

Empezado por diegofernando

puedes instalar un programa en cada estacion cliente que se inicie con su sistema operativo

Esto en parte es cierto por que para poder tener una aplicación distribuida necesitas contar con tecnologia que proporcione este servicio, entre ellos sobresalen DCOM y CORBA, para los cuales el Delphi ofrece un soporte excelente y de facil uso, incluso menciona ambos en su ayuda en Linea.

Suerte -espero haberte ayudado.

[kinobi]

Empezado por uhilari

Esto definitivamente es Falso, en la actualidad existen los famosos Sistemas Distribuidos los cuales se caracterizan por mantener partes del programa en diferentes PCs y comunicarse entre ellas (pueden ser archivos exe o dll), esto permite tener aplicaciones que estan -por asi decirlo- Durmiendo y que esperan una orden para Despertar. Esta manera de programación ya ha sido vista antes.

Esto definitivamente es cierto, pero definitivamente también no contradice lo anterior, por tanto, no, no es definitivamente falso mi argumento, ya que en caso contrario esas aplicaciones durmientes se despiertan ellas solas, y un sistema distribuido se comunica con otro mágicamente sin la intervención de ningún proceso, ¿verdad?.

[uhilari]

Bueno, en todo caso no hablemos de cosas rotundas -aunque yo haya comenzado el asunto-

Empezado por kinobi

un sistema distribuido se comunica con otro mágicamente sin la intervención de ningún proceso

En la comunicación de un sistema distribuido no hay nada de magico, la comunicación se hace a traves del mismo sistema operativo y los sockets (ya que en su mayoria estos sistemas usan el protocolo TCP/IP para comunicarse) y lo unico que hacen es enviar una GUID del Objeto a ser creado y el ID del procedimiento para que sea llamado, pero esto lo hace a un nivel bajo por lo que el programador no se percata de esta operación.

Pero -como dije antes- para que la interpretación de este GUID e ID se de correctamente debe existir un interpret, que en este caso son las tecnologias que anteriormente mencione.

Les recomiendo que visiten este lugar:

http://www.fcharte.com/Default.asp?articulos

[kinobi]

Empezado por uhilari

Bueno, en todo caso no hablemos de cosas rotundas -aunque yo haya comenzado el asunto-

El nivel de rotundidad que tú quieras, pero sigo sosteniendo que (y me cito): "...lo que quiere el compañero es hacerlo sin tener un proceso ejecutándose en segundo plano, estando éste "a la escucha" de peticiones de los clientes, y eso, evidentemente, no es posible.", no es definitivamente falso como tu afirmas, sino todo lo contrario.

Si has leído el resto del hilo, habrás visto que ya se había argumentado antes de tu intervención la posibilidad de servicios distribuidos proporcionados por el sistema (y vuelvo a citarme): "pues sin un proceso que esté "a la escucha" (hecho por tí, por un tercero, o proporcionado por el sistema) va a ser difícil, mejor dicho, imposible.". El que ese proceso (o agente, dependiendo del modelo de sistema) esté dentro de un modelo cliente/servidor o un modelo de objetos distribuidos (y pon el mecanismo que quieras: RPC, RMI, CORBA, DCOM, ...) es indiferente para llegar al punto, en ambos modelos, donde existe un proceso (o procesos) en una máquina (o varias) que dan el servicio solicitado.

Empezado por uhilari

En la comunicación de un sistema distribuido no hay nada de magico, la comunicación se hace a traves del mismo sistema operativo y los sockets (ya que en su mayoria estos sistemas usan el protocolo TCP/IP para comunicarse)

Sí, evidente, mi comentario era irónico.

Empezado por uhilari

y lo unico que hacen es enviar una GUID del Objeto a ser creado y el ID del procedimiento para que sea llamado,

Evidente también. Así se hace en DCOM, en CORBA de forma similar, y también podrías tú, o yo, o cualquiera de los compañeros que tuviésemos tiempo, ganas y conocimientos, crear un mecanismo que permitiese pasar una simple cadena del tipo "Oye, imprímeme el documento: Mi_Documento.pdf en colores y déjamelo en la impresora más cercana a mi puesto"; de tal forma que el sistema envíe esa cadena a un agente (o servidor, o proceso, u objeto de negocio, ...) dentro de la red que sea capaz de interpretar el lenguaje natural y realice la tarea solicitada.

Empezado por uhilari

pero esto lo hace a un nivel bajo por lo que el programador no se percata de esta operación.

Que no se percate no implica que no exista. Es más, obviar el middleware depende del nivel de abstracción en el que te muevas. Si perteneces a un gran equipo de desarrollo y tú estás en el nivel de desarrollo de los interfaces de usuario del sistema, nada de eso te preocupará, pero si trabajas en un equipo pequeño o tú solo, tal vez siendo responsable del desarrollo, instalación y explotación del sistema, entonces sí que tendrás que preocuparte.

Empezado por uhilari

Pero -como dije antes- para que la interpretación de este GUID e ID se de correctamente debe existir un interpret, que en este caso son las tecnologias que anteriormente mencione.

Pues, independientemente al nivel que te pongas, eso es lo que hemos dicho los participantes de este hilo.

Empezado por uhilari

Les recomiendo que visiten este lugar:

http://www.fcharte.com/Default.asp?articulos

Gracias, siempre me han parecido interesantes las opiniones y bibliografía de Charte, espero que tú también encuentres interesante la de Tanenbaum:
http://www.amazon.com/exec/obidos/tg...glance&s=books

[uhilari]

JA JA JA

Parece que kinobi se molesto un poco, mi intencion no era molestarte, pero me parece que deberiamos dejar esto claro, para que los compañeros foristas no se confundan.

Empezado por kinobi

"...lo que quiere el compañero es hacerlo sin tener un proceso ejecutándose en segundo plano, estando éste "a la escucha" de peticiones de los clientes, y eso, evidentemente, no es posible."

Si consideramos a los interpretes como procesos en segundo plano -aunque no me convence la idea- entonces tu afirmación estaria correcta. No habria manera de hacerlo.

En todo caso creo que hemos dado luces para una solución al problema planteado.

Gracias por la página, aunque no comparto todas las opiniones de Tanenbaum siempre me ha gustado leer sus obras.