Ejecutar Remotamente

[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.

[kinobi]

Empezado por uhilari

Parece que kinobi se molesto un poco, mi intencion no era molestarte,

¿Molesto? No, en absoluto.

Llevo varios años participando en estos foros (entre estos y los antiguos casi 2000 mensajes) y todos los que participamos en los mismos siempre hemos tenido el derecho a la réplica. Aun más si alguien declara como falsa la opinión de otro. Tal vez por tu bisoñez en estos foros no conozcas el funcionamiento de los mismos, pero esto sólo es un debate, una contraposición de ideas. Si tú lo consideras un asunto personal, es tu postura, desde luego no la mía.

Empezado por uhilari

pero me parece que deberiamos dejar esto claro,

Como quieras, pero yo lo tengo claro, aun más: clarísimo.

Empezado por uhilari

para que los compañeros foristas no se confundan.

Hasta ahora no he visto que nadie haya mostrado signos de confusión.

Empezado por uhilari

Si consideramos a los interpretes como procesos en segundo plano -aunque no me convence la idea-

Qué quieres que te diga, utilizando entes abstractos como intérpretes, agentes, objetos de negocio, ..., se puede "enmascarar" (ojo a las comillas) la realidad y apartarse de los detalles de implatación todo lo que quieras, pero al final "cualquier cosa" (ojo a las comillas de nuevo) que dé un servicio en un sistema es (o está dentro de) un proceso (o varios).

El modelo distribuido (o de objetos distribuidos) evoluciona desde el modelo cliente/servidor y, por tanto, ambos basados en conceptos comunes; uno de ellos, quizá el más importante, es que existe(n) un proceso(s) que está(n) "a la escucha" de las peticiones de los clientes para darles el(los) servicio(s) solicitado(s).

Empezado por uhilari

entonces tu afirmación estaria correcta. No habria manera de hacerlo.

Vuelvo a insistir, mi afirmación es correcta incluso sin el condicional.

Empezado por uhilari

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

Bueno, yo tampoco conozco a ningún autor con el que esté de acuerdo al cien por cien.

[diegofhernando]

Esta claro que cada cual tiene diferentes puntos de vista acerca del asunto, evidentemente a su manera todos defienden sus ideas y de eso se trata, se han comentado diferentes cosas y estoy seguro que de algo han servido, ahora es mi turno, primero sigo insistiendo que el compañero quiere solucionar su problema desarrollando una aplicación con delphi, entonces las soluciones se las debemos presentar con nuestra queridad herramienta RAD, y son soluciones, por que a pesar de sólo llevar 2 años y algunos meses asistiendo a este foro, la mayoria de las veces he recibido soluciones mis inconvenientes.

Lo que comenta el otro compañero forista acerca de la seguridad, pienso que es solo MAQUILLAJE, es decir, obviamente el echo de tener un puerto abierto representa un riesgo depende del programador implementar sus tareas de seguridad... mi intervencion simplemente pretendia orientar un poco al compañero que plantea el inconveniente... JEJEJE de cualquier forma para eso son los foros, para debatir y confrontar ideas, pero no olvidemos que las personas que ingresamos al foro lo hacemos con el fin de encontrar apoyo en las experiencias ajenas.

Salu2