Hola de nuevo, Mario.

Bueno, parece que esto ha devenido en un intercambio de opiniones y experiencias muy interesante. Espero que todos aprendamos un poco en el camino.

>>No se a qué te refieres con estos problemas A, B, C y D. Cualquier >aplicación mal construida puede tenerlos, pero no veo que tiene que ver >COM+ en ello.
>
>Correcto. Digamos que seria mejor especificar que una aplicacion o objeto remoto AMPLIFICA el problema. Digamos, un ejemplo clasico: (uno mas chevere seria poner un ciclo, pero de esos me da miedo)
>
>loObjetoRemoto.Nombre='...
>loObjetoRemoto.Ciudad='...
>loObjetoRemoto.Pais='...

Bueno, correcto entonces. Si hicieras esto, estarías creando un componente statefull, lo que de plano queda descartado en COM+. El motivo, que tu debes ya conocer, es sencillo: el mismo componente (físico) en COM+ puede estar atendiendo múltiples requerimientos, por lo que en una parte del código mencionado más arriba, mientras un cliente pone "Medellín" en el atributo Ciudad, otro puede estar sobreescribiéndolo con "Cali", por ejemplo.

Es por eso que -efectivamente- uno debe ser muy cuidadoso con estas cosas, al estar en un ambiente mult-threaded (en realidad en VFP es Apartment Model, pero a los fines prácticos es lo mismo).

Incluso debes tener en cuenta que puedes tener solapamiento en la ejecución de codigo. Es por eso que existe (desde VFP 7) la posibilidad de determinar secciones críticas de código, utilizando:

=SYS(2336,1) && Inicio de sección crítica

* Código seguro (generalmente transaccional)

=SYS(2336,2) && Fin de sección crítica

Esto es similar a utilizar un MUTEX en C++ ó .NET para bloquear los demás hilos de ejecución.

>Mi experiencia en desplegar unas 2-4 aplicaciones diferentes en mas de +2000 estaciones de distintos tipos da como resultado un costo *significativo* en cuanto a manteniemiento, tiempo de implementacion y soporte. Teniendo en cuenta que esas aplicaciones instalan y funcionan Ok localmente, el principal punto de falla ha sido en la conectividad remota.

Bueno, pues si, el deployment, si no está bien pensado, puede ser duro. Por eso es preferible utilizar algún mecanismo de instanciación que no dependa de Proxys (utilizando CreateObjectX). Como siempre, es un tema de planificación.

>>¿Porqué COM+ es más de lo que necesitas? Es un modelo muy liviano y está >disponible como servicio desde Windows Server 2000 en adelante (o en NT >como MTS). Respecto a los costos, nuevamente no se a qué te refieres. En >muchos contextos, una buena utilización puede reducirte costos, no >aumentarlos.
>
>Hay va la parte de investigacion. Por experiencia propia, se que lo que uno imagina que se puede hacer con una aplicacion distribuida, y la realidad, genera costos indeseables.
>
>Un ejemplo (que verguenza me da comentarlo) es que leyendo la documentacion de COM+, me dio por poner SetComplete y SetAbort (pues imagine que aplicaba a mi caso, si ya se, no lei lo suficiente) para descubrir mas adelante para lo que servia....

Bueno, es claro. Como con cualquier cosa, antes de comenzar a usar cualquier tecnología debes estar bien seguro acerca de ella. Sobre COM+ y VFP recomiendo una excelente serie de Craig Bernston que tradujo el amigo Jorge Espinosa para MSDN Latam:
http://www.microsoft.com/spanish/msdn/articulos/archivo/mtj/voices/art30.asp
http://www.microsoft.com/spanish/msdn/articulos/archivo/mtj/voices/art25.asp
http://www.microsoft.com/spanish/msdn/articulos/archivo/mtj/voices/art12.asp
http://www.microsoft.com/spanish/msdn/articulos/archivo/mtj/voices/art02.asp

>
>>Y respecto a la compatibilidad, de Windows 98 SE hacia arriba, no veo el >problema (Windows 95 está obsoleto, y por supuesto, descartamos ME de plano >en cualquier discusión, estimo).
>
>Win95 y ME estan obsoletos pero uno no declara un sistema operativo obsoleto y automaticamente la gente actualiza. Aquellos que pueden obligar este tipo de cosas excelente, otros no podemos (pero DESEAMOS!!!!!)

Bueno, todo depende. Nosotros NO soportamos 95 ni ME, y sólo 98 SE hacia arriba. Y tenemos cientos de clientes. Ofrecemos alternativas, como utilizar Terminal Services, etc, pero finalmente los pocos (creo que nada últimamente) negocios que perdemos, los ganamos en menor costo de soporte. Hay que saber buscar oportunidades, nosotros somos partners de MS, así que incluso podemos vender los upgrades. ;-)

>>¿De veras? ¿Sabes en que está basado .NET Enterprise Services?
>
>Si. Pero uno para que usaria .NET Enterprise Services si .NET remoting resuelve la comunicacion? Muy pocos casos para el tipo de soluciones normales...

Hmmm... Hay un tema de concepto aquí. Aunque Remoting permite definir objetos Single Call, no tiene un mecanismo de pooling, porque no es un servidor de componentes, sino un mecanismo de comunicación. Si necesitas un servidor de componentes transaccionales, sigues cayendo en COM+.

>>En todo caso, lo que podemos decir que corre riesgo de desaperecer es .NET >Remoting, casualmente, ya que el próximo modelo (Indigo) puede >reemplazarlo, no siendo totalmente compatible.
>
>Arghhhh!!! En fin, ya lo sabia sobre avalon y winforms, pero no lo de .NET remoting.
>
>Pero no invalida el punto. MS "recomienda" en .NET el uso de SOAP o Remoting y solo para los casos que lo justifiquen, COM+.

De nuevo, son cosas diferentes. Web Services ó Remoting (incluso Indigo, hasta donde he visto), son sólo mecanismos de comunicación (RPC o marchalling de objetos), mientras que COM+ es un servicio de componentes que provee mecanismos de pooling, un contexto transaccional, etc. Una cosa no implica la otra, aunque la combinación puede dar interesantes resultados en muchos casos.

>>No he visto nada de esto, así que no lo se. Suena interesante aunque no >entiendo bien tu explicación.
>
>Lee esto, muy enfocado al producto que venden pero muy clara la idea. Es similar a .NET remoting y me *imagino* a Indigo (no le he prestado mucha atencion a esto), pero mas bien es interesante porque aisla mucho al desarrollador precisamente de estos cambios:
>
>http://www.remobjects.com/articles/?id={602D25FB-F229-4502-8C90-36396EFB0FB5}

Es muy interesante. No lo he visto a fondo, pero me preocupa un poco la idea de utilizar mecanismos propietarios, que son muy buenos mientras dominas ambos lados de la comunicación. Como si no tuviesemos ya suficientes mecanismos "standard". 8-D

Pero trataré de dedicarle un poco más de tiempo en cuanto pueda, para ver exactamente hasta donde llega la solución.

>>No es malo. Es que no funciona. En la mayoría de los casos, mantener estado >en un componente que está bajo pooling implica corrupción de datos.
>
>Ok, no se que tan bueno sea Fox al manejar memoria en 24x7. Pero un servidor con full estado SI funciona. Pero lo que he hecho/conozco no es con FoxPro....

Lo que digo que no funciona es utilizar componentes statefull bajo pooling (COM+ por ejemplo). La sola posibilidad de utilizar pooling choca contra el mantener estado.

>>Esto está bien como consejo, salvo que guardar un array si sería mantener >estado, y además en forma totalmente volatil. La única solución es en una >tabla o archivo de algún tipo.
>
>Aqui me perdi. Una matriz no esta en memoria y se libera facilmente? No se que es volatil en este contexto y desde que tengo memoria el manejo de estado en memoria es el mas usado y mas simple.... y rapido.

Es que en esta arquitectura no puedes depender de nada que tenga persistencia a nivel del componente. Si guardas algo en memoria, puede no estar allí la próxima vez que accedas, como puede ser reescrito por otro cliente. Básicamente, debes programar de modo que tu componente se instancia, ejecuta un método, y se destruye (y al destruirse arrastra todo cuando quede en su contexto de ejecución, como por ejemplo cualquier cosa en memoria).

Por supuesto que es un giro drástico en la arquitectura de tus clases. Eso nadie lo niega.

>>Tampoco puedes poner un timer en un componente dentro de COM+. Me temo que vas a derrumbar el servicio rápidamente.
>
>No un timer de USUARIO, o sea, como el que viene en la paleta de Fox.....

De nuevo, un timer (de cualquier tipo) dentro de un componente no tiene sentido, porque no tienes control sobre su tiempo de vida. Otra cosa sería tener un servicio corriendo en forma programada en el mismo servidor (u otro) que instancie uno o más componentes para hacer alguna tarea, o interactúe directamente con la DB, etc.

Puede que tarde en responder estos días porque estoy preparando un curso que daré durante toda la próxima semana, pero sigo interesado en el tema, así que ¡adelante!

Un abrazo,