Hola, Mario.

>¿Estás seguro de lo que estás diciendo?

Mas o menos???

>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='...

Es tentador hacer esto, pero es mejor:
loObjetoRemoto.Actualizar(Nombre, Ciudad, Pais)=Para pocos parametros pero probablemente aun mejor:

loObjetoRemoto.Actualizar(AquiUnArrayOXMLOSimilar)
Entendiendo que ademas, es mejor enviar un conjunto de datos que una sola fila, asi lo normal sea una sola fila...

Me refereria a estudiar mas sobre el diseño de aplicaciones de este tipo que a especificamente COM+...

>Nuevamente, no se a qué te refieres con esto. Hay maneras de instanciar >bjetos remotos bastante fácilmente, si se complica crear y distribuir un >proxy. Puedes buscar un artículo de Pablo van Diest al respecto en UTMag

(No sabia que con Fox no era necesario el uso de proxy..chequeare esto a ver si nos simplifica un poco la vida!) pero para ver porque dije lo que dije:

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.

Por eso, especifique: si hay un numero CONSIDERABLE de despliegues. Un despliegue de 1-50/100 maquinas solo requiere un poco de quebrarse el coco al principio . Por otro lado, el problema real va en el DCOM mas que en el COM/ActiveX como tal. En fin, no conozco ninguna empresa local y se de varias en otros paises que tienen experiencias negativas similares, que obviamente se podran minimizar, eludir o amplificar dependiendo de otros factores.

El tamaño y complejidad determina mucho este asunto. Otro factor es elegir mal las tecnologias y la mezcla entre ellas (nos fue MUUUUY mal usando Fox 6+COM+DCOM+ADO....) obviamente a estas alturas y con Fox 8 se que la cosa cambia pero igual no anulan lo ocurrido..... (igual problemas hay, incompatibilidades con los proveedores OleDB-principalmente los de Fox- diferencias de versiones o DLL hell, y cosas asi). Mientras mas ha pasado el tiempo, mas me gusta el modelo de desplegar una aplicacion compacta, con ninguna o minimas dependencias en cosas como el IE y asi por el estilo.

>Está claro que COM+ es mucho más que un mecanismo de instanciación remota, >pero qué tiene que ver con esto. Si Ricardo no necesita -por ahora- otra >cosa, puede utilizarlo para esto con buena performance, confiabilidad, etc.

Porque hay modelos mas simples y con menos puntos de falla y mas economicos de desplegar. Desafortunadamente son pocos usados por la comunidad de Fox (y menos conocidos). Los enlaces que di dan una idea de lo que hablo...(mas no necesariamente sea la unica y no invalida el uso de COM si de todas maneras resuelve el asunto de manera satisfactoria. La mejor forma de apreciar una herramienta o tecnologia es ver como se soluciona de formas diversas lo mismo), por otro lado, la ideas se compilan en cualquier lenguaje y veras puntos interesantes que ayudarian al usar COM+

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

>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!!!!!)

Sin embargo, si, la mayoria usan(ban) win98 y por este año se esta viendo un aumento significativo de maquinas winxp...Espero dentro de poco no tener que ver mas WinME ni Win95 ni Win98....

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

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

>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}

Hay se ve claramente la parte de sencilles...

>Mas bien parece un escenario LAN, y én ese contexto, lo más probable es que la
>seguridad actual sea muchísimo más laxa que lo que implica solamente poner >un servicio de este tipo.

Si me imagine un servidor publico....baaa, en ese caso, puede ser mas simple y se puede relegar al que maneje la red. Por otro lado, si la aplicacion va a estar en ambientes donde no hay ni dominio ni alguien que monte esto, puede resultar un poco mas economico y si menos exigente en tiempo de implementacion poner un minimo de seguridad. O sera que me he vuelto desconfiado con el tiempo....

O sea, y si a los clientes les da por poner en un servidor WEB el servicio que se supone LOCAL??? y no saben nada de encripcion? y si son tan ignorantes, como en mi caso, que monte el ISA server y luego un tipo lo reviso (a los 3-4 MESES) y me dijo que todo lo HICE MAL!!!! ARFGHHHHHH!!!!!! y que estaba TODO abierto!!!! Haaa,y yo que creo saber de estas cosas....

Prefiero tomar las decisiones yo si puedo. Y no confiar en que los usuarios lo haran. Ahora me dio cuenta, que si soy desconfiado!!!

Y en el curso que esta haciendo MS sobre seguridad y esas cosas se me crispan los nervios aun mas....

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

>El modelo de ASP "es" stateless. El mecanismo de sesión "simula" un >mantenimiento de estado, pero no lo mantiene realmente.

Ok!


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

O las matrices en Fox se corrompen facilmente? Te refieres a la fragmentacion de la RAM en general???

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

Gracias por recordar...