Necesito implementar dos aplicaciones que intercambien datos entre ellas. Ambas aplicaciones se ejecutarán en PC separadas que son parte de una LAN.Intercambio de datos entre dos aplicaciones en PC en LAN
¿Cómo podemos hacer esto en Delphi?
¿Hay algún componente gratuito que facilite el intercambio de datos entre aplicaciones en las PC?
Si lo estoy escribiendo yo mismo (casi) siempre uso conectores para intercambiar datos entre aplicaciones.
Es liviano, funciona bien en la misma máquina, en la red local o en Internet sin cambios y le permite comunicarse entre aplicaciones con diferentes permisos, como servicios (los mensajes de Windows causan problemas aquí).
Puede que no sea un requisito para usted, pero también soy un fanático de los transportes independientes de plataforma, como TCP/IP.
Hay muchas opciones gratuitas para Delphi. Aquí hay algunos que yo sé. Si le gusta bloquear bibliotecas, mire Indy o Synapse. Si prefiere no bloquear, consulte ICS.
Probablemente la manera más fácil es leer y escribir un archivo (o posiblemente un archivo por dirección). También tiene la ventaja de que es fácil de simular y rastrear. Aunque no es la opción más rápida (y definitivamente suena coja ;-)).
El acceso concurrente a un archivo a través de una red no es seguro en absoluto. Es perfectamente seguro si el contenido es de solo lectura. Pero si desea que se modifique el archivo, no es una buena idea. Debido a la comunicación de red, nunca puede estar seguro de que el archivo esté bloqueado, incluso si usa las API de Windows correspondientes. Puede ser una pesadilla para depurar. –
Observe las soluciones que utilizan interfaces de tipo "Llamada a procedimiento remoto". Yo uso RemObjects SDK para este tipo de cosas, pero hay versiones de código abierto de RealThinClient que funcionarían igual de bien.
Ambos le permiten crear una conexión que para la mayoría de su código es "transparente", y solo llama a una interfaz que envía los datos por el cable y obtiene resultados. A continuación, puede programar cómo suele hacerlo y olvidarse de los detalles de los zócalos, etc.
Según lo que he leído, RealThinClient es gratuito solo para fines de desarrollo. ¿Cuál es la imagen real de RTC? –
Verifique con RTC el estado. Creo que es como MySQL en que hay versiones "antiguas" que están abiertas y se cobra la actual. Para mí, vale la pena pagar RemObjects SDK, ha sido muy flexible. – mj2008
Solía usar Mailslots si necesitaba comunicarme con más de una PC a la vez ("transmisión") a través de una red, aunque había es la advertencia de que los mailslots no están garantizados.
Para 1-a-1, las Canalizaciones con nombre son una forma de Windows de hacer este tipo de cosas, básicamente se abre un canal de comunicación entre 2 PC y luego se escriben mensajes en la tubería. No es sencillo para empezar, pero es muy confiable y la forma recomendada para cosas como Servicios de Windows.
MS ofrecen Canalizaciones con nombre como una forma alternativa de comunicación con un servidor SQL (que no sea TCP/IP).
Pero, como dijo Bruce, TCP/IP es estándar e independiente de la plataforma, y muy confiable.
Los puntos de distribución y los conductos con nombre utilizan TCP/IP para la comunicación entre máquinas, y son opciones de protocolo viables entre aplicaciones en la misma red. – skamradt
Este es uno de esos casos en los que realmente no hay una "mejor" respuesta ya que casi todas las tecnologías ya discutidas se pueden usar para comunicar con precisión entre dos aplicaciones. La elección del método que se utilizará realmente se reducirá a la naturaleza crítica de su comunicación, así como a la cantidad de datos que se deben transferir de una estación de trabajo a otra.
Si su comunicación no es sensible al tiempo o crítica, entonces una simple encuesta de una base de datos o archivo a intervalos regulares podría ser suficiente. Si su comunicación es crítica y sensible al tiempo, puede ser conveniente ubicar un servidor TCPIP en cada cliente. Si solo es sensible al tiempo, entonces mailslots hace una buena elección, si es crítico pero no sensible al tiempo, entonces canaliza el nombre.
Antes de elegir una técnica, debe caracterizar la comunicación de acuerdo con su rendimiento, granularidad, latencia y criticidad.
Rendimiento: ¿cuántos datos por unidad de tiempo necesitará para moverse? El rango de valores posibles es tan amplio que las aplicaciones con la tasa más baja y la tasa más alta casi no tienen nada en común.
Granularidad: ¿qué tan grandes son los mensajes? ¿Cuántos datos necesita la aplicación receptora antes de poder usar el mensaje?
Latencia: cuando una aplicación envía un mensaje, ¿qué tan pronto debe verla la otra aplicación? ¿Qué tan rápido desea que la aplicación receptora reaccione a la aplicación de envío?
Criticidad: ¿por cuánto tiempo puede dejarse sin atender un mensaje recibido antes de que sea invadido por un mensaje posterior? (Esto generalmente no es importante a menos que el rendimiento sea alto y el almacenamiento de mensajes sea limitado.)
Una vez que haya respondido a estas preguntas, puede comenzar a preguntar acerca de la mejor tecnología para su situación particular.
-Al.
+1, aunque agregaría al punto de "criticidad": ¿Se puede permitir que los mensajes se reciban fuera de orden o incluso se eliminen por completo? – mghie
Los mensajes generalmente están dentro de 10k bytes en cualquier punto del tiempo. Todos los mensajes se guardarán en un formato propietario compatible con un software de análisis estadístico de terceros. –
Excelente punto mghie - Agregaré orden y confiabilidad a mi concepto de criticidad. -Al. –
DCOM solía ser un buen método de comunicación entre procesos. Este fue también uno de los puntos fuertes de Delphis. Hoy quisiera fuertemente consejos contra usarlo.
Dependiendo de la naturaleza de su proyecto que pienso que si bien
DCOM está en desuso, y tengo muchos problemas para usarlo. Incluso está deshabilitado en la versión más reciente de Windows Server AFAIK. –
He usado los componentes de multidifusión Indy de la biblioteca (IdIPMCastClient/Servidor) para este tipo de cosas muchas veces. Las aplicaciones solo envían XML entre ellas. Rápido y fácil con requisitos mínimos de conexión.
Para la integración de aplicaciones Delphi, un message oriented middleware podría ser una opción. Los corredores de mensajes ofrecen entregas garantizadas, balanceo de carga, diferentes modelos de comunicación y funcionan en múltiples plataformas y en varios idiomas. de código abierto intermediarios de mensajes de mensajes incluyen:
(Renuncia - Soy el autor de bibliotecas de cliente Delphi/Free Pascal para éstos servidores)
El software nunca tendrá más de 4 PC en LAN, por lo que nunca será el problema. No quiero emplear un servidor para esto. ¡Usar un servidor es como llamar a un elefante para recoger una ramita! Gracias por su sugerencia. –
Una posibilidad podría ser "compartir" objetos a través de la red.
Es posible con un ORM cliente-servidor como nuestro .
Estos libraires de código abierto funcionan desde Delphi 6 hasta XE2, y usan JSON para la transmisión. Se incluyen algunas características de seguridad (que implican un RESTful authentication mechanism) y puede usar cualquier base de datos, o ninguna base de datos.
Consulte en particular el first four samples provided, y la documentación asociada.
Lo siento por mi ignorancia, pero ¿qué es el bloqueo y el bloqueo? Nunca me he encontrado con estos términos, incluso después de la programación de más de 15 años. De hecho, nunca me he encontrado con un requisito así hasta la fecha. Esta es la primera vez que un cliente solicita una instalación que permita que nuestras aplicaciones que se ejecutan en diferentes PC se comuniquen e intercambien datos entre ellas. En realidad estaba planeando adoptar DCOM, pero el hecho es que usar COM en Delphi es puro Pain en ... –
He tenido experiencias realmente malas con DCOM desde el MIDAS original, que usaba DCOM como el transporte predeterminado. Si decide probarlo, investigue primero. El bloqueo de llamadas detiene la ejecución del código hasta que la llamada ha finalizado. Para aplicaciones interactivas, estas se deben usar en hilos. Las llamadas sin bloqueo devuelven el control de inmediato y le notifican con un evento cuando la llamada se haya completado. Ambos tienen sus ventajas y desventajas. –
COM en Delphi es probablemente la forma más fácil de usar COM, pero generalmente no es la mejor manera de trabajar en una red. El bloqueo y el no bloqueo se relacionan con la forma en que el sistema operativo maneja el hilo que inicia la E/S (una secuencia o proceso bloqueado no se ejecutará hasta que se desbloquee). El bloqueo de E/S hace que el programador del sistema operativo no programe el subproceso hasta que se complete la E/S. La E/S sin bloqueo no bloquea el hilo, el hilo sigue en ejecución, pero necesita utilizar una devolución de llamada o un sondeo u otro mecanismo para notificar su finalización. –