Acerca de .Net Remoting Ayuda

"Edie" escribió en el mensaje
news:

Buenas tardes grupo, en verdad no es una pregunta, es que necesito sus
opiniones y comentarios.

En el lugar donde trabajo hemos desarrollado una aplicación hace un par de
años, ahora se ha decidido hacerla de forma distribuida, usando .Net
Remoting
obiamente, pero a la hora de realizar cualquier proceso en el servidor
tarda
más o menos 1 segundo y medio más de como lo hace la que no utiliza el
Remoting, Lo que quiero saber es :

1- Es esto normal?
2- Si no lo es, alguna sugerencia
3- hay una forma de que esto se haga más rápido?

de antemano gracias por sus comentarios y/o sugerencias ;)... La base de
datos está realizada en MSSQL server 2000 y la aplicación en VB.Net.

Hola.

No tengo mucha experiencia con Remoting, pero me parece que una cierta
demora es, hasta cierto punto, normal: la llamada al procedimiento debe ser
"empaquetada para su transmisión", enviada al servidor, desempaquetada,
puesta en una cola, y atendida. Luego el resultado es empaquetado, devuelto
al cliente, desempaquetado y devuelto a la aplicación. Esto debe imponer una
cierta sobrecarga.

La unica solución es rediseñar parte de la aplicación para reducir la
dependencia del servidor y la frecuencia de los dialogos C/S.

Un ejemplo típico es el proceso de un documento con detalles. Normalmente
escribimos algo del tipo de:

If elDocumento.Salvar Then
For Each Detalle In losDetalles
elDocumento.AgregarDetalle(Detalle)
Next
End If

si vas a realizar el proceso en un servidor, lo ideal seria:

Dim Contenedor As PaqueteDocumento
Contenedor.Documento = elDocumento
For Each Detalle In losDetalles
Contenedor.AgregarDetalle(Detalle)
Next
ObjetoRemoto.ProcesarContenedor(Contenedor)

de esta manera reduces la cantidad de llamadas a traves del cable (que serán
tanto mas pesadas cuanto mas lenta sea la linea de comunicacion). Esta unica
llamada es mas pesada que cualquier llamada individual, pero la sobrecarga
de pasar a traves de la infraestructura de remoting se produce solo una vez.

La otra recomendación es que trates de mantener la mayor cantidad posible de
información del lado del servidor: todos los registros de consulta frecuente
(condiciones de venta, tablas de descuentos, parametros de la empresa,
parametros contables, lo que necesites) pueden estar en colecciones o
conjuntos de datos del lado del cliente. De esta manera logras reducir la
dependencia con respecto al servidor.

Uno de los beneficios para el desarrollador de las aplicaciones OO, es la
no-contextualidad de los objetos y las operaciones (una llamada a un metodo
o propiedad de un objeto debe producir el resultado esperado sin que se
requiera ninguna precondición, idealmente). Para lograr esa independencia,
los métodos con frecuencia deben duplicar alguna operacion. Y esa
duplicacion, cuando la infraestructura es lenta, puede hacer que los tiempos
de respuesta se hagan inaceptables. La solución para ese tipo de problema,
que te permite mantener la no-contextualidad (un requisito del bajo
acoplamiento) es crear objetos "del lado del cliente": llamas al objeto
remoto, que te devuelve un objeto que se almacena localmente, y continúas el
proceso contra el objeto local. Puede ser conveniente almacenar estos
objetos en colecciones o tablas locales, asignandoles un "tiempo de vida", y
cargarlos de este bufer mientras no se venzan. Cualquier recurso que te
permita depender lo menos posible del servidor remoto te ayudará a mantener
un nivel de eficiencia aceptable.

La poca experiencia que tengo me sugiere más o menos este orden de
distribución:
1.- Mantener local todo lo que sea posible
2.- Utilizar llamadas directas a procedimientos almacenados en el
servidor
3.- Utilizar objetos remotos.

Si por alguna razón se requieren clientes ultralivianos (por ejemplo porque
las reglas de negocio son tan fluidas que el costo de actualizacion de los
clientes resultara demasiado elevado) puede ser conveniente reimplementar la
aplicación en ASP.NET: es trabajoso, pero normalmente no se esperan bajos
costos de desarrollo en aplicaciones distribuidas.

Salud!