CLR: .Net / Mono / Boo / Otros CLR > VB .NET
Programación Remota
nuke2612:
Hola!
Después de estar mirando diversos lenguajes y sistemas para poder hacer una aplicación distribuida evitando el mantenimiento y la instalación en los Pcs cada vez que modificamos un proceso (en nuestra Intranet) ... no llego a ninguna conclusión sobre qué lenguaje utilizar.
REF: CLARION
Lo más avanzado que he podido lo ha logrado la compañía Softvelocity http://www.softvelocity.com/ . Esta compañía utiliza como lenguaje de programación el Clarion y ClarioNet como sistema de distribución a través de Web y un pequeño programa en los clientes. Con este sistema programa la aplicación con formularios, procesos, etc... y los clientes siempre utilizan la versión disponible en el servidor, encargándose el ClarioNet de enviar simplemente pantallazos a tiempo real.
REF: VISUAL . NET
Lo más remoto que he visto es la programación en Visual .Net es ASP.NET. Que podemos hacer páginas con bastante funcionalidad y ejecutando procesos en el servidor sin viajar los datos por la red.
REF: NET REMOTING
El gran misterio... la información es escasa y poco clara. La poca información que he conseguido, me imagino que la implementación en Net Remoting funciona igual que una aplicación Cliente/Servidor, utilizando servicios (igual que los web servicices) pero a través de TCP.
Pues eso...solo comparto esta información para ver si alguien puede aclararme las dudas, errores, y asesorarme en qué lenguaje de programación se orienta más a la Programación Remota.
Gracias,
:hola:
Snaft_J1:
haber si entendi...
la idea es:
crea una aplicaicon distribuida donde todos los clientes compartan los archivos base creados en el servidor?.
bueno yo te recomendaria .NET
hace poco tiempo hice una aplicacion utilice remoting para crear la aplicacion servidor
y en el cliente pero fue poco(en el cliente no) y lo que se realiza es trabajar algo parecido al TCP solo que este es mas enfocado ha Canales (Channel) y para lago mas enfocado al TCP deberias utilizar las clases derivadas para el Winsock jejeje...
lo que mi aplicacion hace es ?
activar un servidor o proveedor de datos tipo consola y manipular el acceso mulisesion al componente en cargado de la manipulacion de los datos..
los clientes manejaban todo con multi sesion he identifiacion enmascarada con Xml, sabiendo que son aplicaciones Win32 y mantienen la persistencia de la informacion a traves de archivos xml pero la programacion no fue muy extensa en los cliente mas en el server.
mira en la universidad.NET de microsoft hay un pokitito de informacio sobre remoting, por que en realidad si que es escasa... <_<
si necesitas ayuda o conversar con migo agreame a tu MSN.
espero me aclares si no te he comprendido vale.
enjoy it..
nuke2612:
Hola!
Gracias por responder!.
Ummm exáctamente el objetivo es poder crear una aplicación común de almacén (formularios por un tubo, entradas, salidas, informes, etc...), de tal manera que cualquier actualización se aplique de forma inmeditata a todos los usuarios sin necesidad de estar actualizando localmente la aplicación en los Pcs. Algo así como el ASP.NET pero quizás con formularios algo más robustos y flexibles. Sé que el ASP.NET ha mejorado bastante con opciones como runatserver, pero quiero indagar antes de meterme más a fondo.
Hasta ahora lo que he visto de Net Remoting no me aclara cómo debo hacerlo. Sé que tengo que elaborar una parte servidor y otra cliente, pero precisamente eso es lo que quiero evitar, elaborar una parte cliente que tenga que ser instalada cada vez que hago una modificación. Además no he visto ningún ejemplo que trate el tema con formularios, solo con servicios parecidos a los Webs service y aplicaciones de consola.
Gracias nuevamente,
:hola:
Snaft_J1:
tambien puedes crear un servicio web y establecer una referencia al mismo...
pero bien recuerda que la funcionalidad de win32 para .net mejor tanto que no es necesario instalar.
lo otro es que lo puedes crear de tal forma que si existen cambios o una nueva version el solitito pueda actualizarse y sin mucha demora :rolleyes:
quizas es un poco iluso no, tal cual como los antivirus.
hoy endia son aplicaciones win32 que accesan a internet para conectarse ha un servicio web el cual solo le expone los resultados de los datos y el cliente no necesitaria variaciones, solo con cambiar el componenete o aplicarle modificaciones todos los clientes quedarian con esas mejoras, claro teniendo en cuenta que el cliente solo envia cadenas xml o texto y el que procesesa si son inserciones,actualizaciones,busqueda etc.. seria el componente espero ser claro.
con esto el cliente solo seria igual siempre, pero recuerda que la finalidad de los Win32 es aprovechar la riqueza del OS en donde esta el aplicativo por lo tanto no estara en el server poque el procesamiento se realiza de modo compartido y no en el server unicamente (Modelo Cliente/Servidor) o me equivoco?...
pero podrias poner un solo cliente en un recuerso compartido habilitando la opcion <SerialiZable> para que todos desde distintos puntos de red lo ejecuten y siempre veran el mismo, claro que debes instalar el NetFrameWork en las maquinas eh.
Un saludo.
nuke2612:
Gracias nuevamente! de vedad que me estás ayudando bastante.
... ummm! crear un recurso compartido y ahí poner el cliente (SerialiZable). Evidentemente el cliente tendrá una tamaño mínimo ya que el gran peso lo soporta el FrameWork que debe estar instalado en las máquinas.
... Si pongamos por ejemplo un formulario que corresponda a la creación de una factura (típico programa). Tengo dudas sobre cómo distribuir este proceso.
1.- Está claro que el formulario iría en la parte cliente ¿Qué procesos comúnmente van en la parte cliente y cuáles en la parte servidor?
2.- La parte Servidor, sería una aplicación que ejecutamos como servicio, y éste atiende las peticiones de los clientes?
3.- Un sólo servicio en el servidor podría efectuar distintos y distintos insert, updates, select, etc... ?
4.- La Serialización es por clases, por proyecto, ..., es decir se Serializa el cliente entero o debo indicárselo clase a clase?
Como verás soy un novato novato ... :hola:
Navegación
[#] Página Siguiente
Ir a la versión completa