COM + ( Problema y dudas )

Buenas noches y muchas gracias por leer esta COM+ Historia ( no no se
confundan no es el señor de los anillos "el retorno del rey" ) es una
emergencia

bueno tratare de Ilustrar mi problema ( Espero que en algun momento
alguien haya estado en esta situacion de emergencia )
en realidad son varias preguntas en un solo mail espero su paciencia
Gracias
miles.

LA HISTORIA
Todo comenzo cuando se me presento la posibilidad de atender a un cliente
algo mas grande de lo acostumbrado
este cliente contaba con sucursales por todo el pais y necesitaba un
software que controle todas sus ventas pedidos y control de almacen ( la
necesidad tipica no ? ) pero la diferencia radicaba en que las sucursales
debian conectarse remotamente a un solo servidor de base de datos que se
ubicaba en la central de la empresa bueno entonces el plan era mudar
nuestros sistemas ( los clasicos cliente/servidor LAN ) a una arquitectura
de 3 capas ( todos mis desarrolladores tienen experiencia en vb6 Solamente
y
por el momento ) . entonces decidimos hacer nuestros dll ( capa de
negocio ) en visual basic 6 porque no nos quedaba otra
no habia tiempo para investigar otros lenguajes y seguimos algunas normas
recomendadas por n libros que encontramos que serian las siguientes :

LAS MEDIDAS DEL CASO
1- no utilizar "selects" genericos en los llamados a la capa de datos es
decir no utilizar tanto "*" y etc

2- no pasar objetos a las funciones o procedimientos que contienen los
componentes ( objetos como un recordset por ejemplo )
( esta norma la tenemos en cuenta sin embargo aun no la estamos aplicando
porque en nuestros desarrolladores se ha vuelto algo adictivo pasarle
recordsets al
componente lo hace mas sencillo segun comentan todos )

3- traer la informacion desde la capa de datos , trabajarla localmente con
la capa de presentacion ( hecha en vb6 naturalmente ) , y luego capturar
los cambios
locales y transferirlos al servidor de base de datos ( capa de datos )
esto
lo realizamos con el metodo Save que tiene el Recordset de ado y graba los
recordsets a disco duro ( tampoco sabemos si esta tecnica es : bien vista
?, es comunmente usada ?, es pesima ? , o es un standard ) pero lo que
nosotros si sabemos es que nos ayuda en la capa de presentacion
tremendamente .

4- estamos programando todas las reglas de negocio y validaciones en los
componentes dlls es decir estamos tratando de programar al estilo 3 capas
y
pensar de
esa manera

5- utilizamos la politica de conectarnos (pasando la cadena de conexion
osea
un string como parametro) luego ejecutar las tareas en el sqlserver
y automaticamente nos desconectamos claro esto tiene que ver con el
punto
de los recordsets y el metodo "SAVE" del mismo

6- la capa de presentacion no tiene ninguna relacion con sql server solo
los
componentes se comunican con el

7- aun no hemos utilizado el objeto contexto y agrupar procesos en un solo
contexto ( para no complicar la cosa )

8- bueno si utilizamos commit y rollbacks en la comunicacion con la base
de datos

..Y BUENO esa son todas las precauciones y criterios que hemos seguido
para
hacer el modelo de 3 capas AHORA LES DESCRIBO :


LAS DUDAS ,MITOS , TEMORES Y PROBLEMAS
"el gran problema" ya estan rediseñadas todas mis aplicaciones bajo esta
programacion que he descrito pero "HASTA AHORA" NO hemos probado sacar
los
dlls de vb6 e instanciarlas en el servidor de componentes de microsoft )
no lo podiamos hacer en nuestra misma oficina porque supuestamente
estabamos
SOLO en una red de trabajo Lan y conectados a internet via ADSL de
velocidad basica y sin ningun numero ip ( por lo menos creo que esa era
la
razon o la excusa ) . CLARO OBVIAMENTE podiamos probar colgando todos los
componentes en mi servidor de componentes y que por la red local las
aplicaciones
reconocieran al servidor y trabaje ( pero esto no probaria la performance
del viaje REAL de la informacion por internet que es lo que nos interesa
ahora )
ahora nos queda 7 dias para la primera entrega y van a querer hacer
pruebas
conectando las sucursales y nosotros no tenemos idea de que va a ocurrir
:(
AHORA IMAGINATE EN EL PROBLEMA QUE ESTOY !! ahora he subdividido mis
interrogantes el que sepa alguna o todas en serio ...GRACIAS :

0) me doy un balazo en la cabeza ? ( no verdad ? ) :)


1) me falto alguna consideracion importante en la programacion de
componentes ? o algo para mejorar la performance via remota ? o lo hice
todo
mal ? , tengo que
hacer algun seteo importante al momento de compilar la dll de vb6
aparte
de la compatibilidad binaria y la propiedad Multiuse ?

2) Cual seria la configuracion mas adecuada de mis componentes ? ( estoy
hablando del seteo que se realiza en el component manager )
tenemos los temas del < JIT , colas de componentes , colas de mensajes
, hilo simple y multihilo ( que no entendi bien) , agrupacion de
conexiones
, agrupacion de objetos , compatibilidad con transaccion , apodos ,
eventos
com+ > y n temas diversos que me hicieron entender muchas cosas y a
la
vez confundirme o agarrarle respeto a todo esto PERO mis componentes son
simples , en contadas oportunidades uno de mis componentes llama a otro
componente , con las justas los metodos de un mismo componente se llaman
entre si , esto para evitar excentricidades en los seteos y bueno si
quieren
saber sobre la carga de trabajo que tendran los componentes pues tendran
unas 15 sucursales conectandose con la central al mismo tiempo en total se
emitiran 100 documentos de venta diario entre todas las sucursales lo que
en
realidad no me parece exagerado ( POR LO MENOS NO LO ERA EN
CLIENTE/SERVIDOR LAN )

3) conversando con amigos administradores de red he capturado algunas
opiniones que me han hecho entrar en panico algunos dicen que :
- no se puede utilizar un servidor COM+ si no tienes un ip publico lo
que me parece algo logico ? o no ?
- es una burla total tratar de implementar COM+ con ADSL en el
servidor de componentes y en el servidor de datos aunque tengan ip
publicos
que lo mejor es tener linea dedicada si se quiere hacer algo serio
( cuando se enteren de esto mi cliente me van a crucificar !!! )
- que se necesita de 512 kb de transferencia para trabajar ok ( cual
entonces seria una velocidad aceptable ? con la carga que he descrito ? )

4) algunos libros y programadores de visual C dicen que realizar
componentes en visual basic 6 no es recomendable que es mejor hacerlos en
visual c pero en ningun lado cuentan PORQUE o que es lo que visual basic
como componente NO HACE !!! ???????????????

5) una vez que sigo los pasos del "asistente para la exportacion de
aplicaciones COM" solo tengo que llevar ese instalador a las maquinas de
las
sucursales
instalarlo alli y problema solucionado ? o es que tengo que poner a
esas maquinas remotas "NECESARIAMENTE" en el mismo dominio y que las
sucursales se logeen al windows server de la central ? ( actualmente las
sucursales solo son maquinas con internet no tienen ninguna relacion ni
dependencia con la central )
necesito saber como debo configurar las maquinas remotas

6) creo que sera necesario utilizar la agrupacion de conexiones del
odbcad32 en el server bueno supongo ?

7) porque consultando algunos dicen que no hay nada mejor que hacer la
capa
de presentacion en ASP ? es porque la capa cliente estaria mas cerca al
servidor de
base de datos ? ( esto si se supone que IIS , ms com manager , y sql
server estan todos en una LAN ) o existe otra razon ? al final los dos
estan instanciando el
mismo com+ asi que aparte de lo descrito la velocidad y performance
deberia ser la misma

Colegas Me quedan 7 dias ( esto paso de ser el señor de los anillos
a
"THE RING" ) espero poder hacerle un fix a todo lo que he hecho
para que pueda caminar y escoger la mejor solucion de infraestructura
para
la comunicacion .



OTRA VEZ GRACIAS POR LEERLO .

Hola, como nadie te contesta espero esto te ayude, yo desarrolle un

que trabaja en una red WAN, con SQL Server 2000 VB6 con ADO, el problema
principal estaba en el tiempo que demoraba las consultas sql y el ancho de
banda que utilizaba, esto fué todo un experimento, trabaje con un ancho de
banda de 1 MB y una consulta de tabla cruzada donde intervenía 3 o 4

en una cantidad de datos muy grande ( mas de 50.000 registros) esta

demoraba entre 20 y 30 minutos, no sibió ya que el tiempo de espera era
demasiado, la solución, un sistema que trabaja localmente y otro aparte

actualizaba la base de datos (tomando en cuenta que cada modificación no
perturbaba a ningún otro cliente del sistema.).
Eso.
Salu2
"kamus" escribió en el mensaje
news:
> Buenas noches y muchas gracias por leer esta COM+ Historia ( no no se
> confundan no es el señor de los anillos "el retorno del rey" ) es una
> emergencia
>
> bueno tratare de Ilustrar mi problema ( Espero que en algun momento
> alguien haya estado en esta situacion de emergencia )
> en realidad son varias preguntas en un solo mail espero su paciencia
> Gracias
> miles.
>
> LA HISTORIA
> Todo comenzo cuando se me presento la posibilidad de atender a un

> algo mas grande de lo acostumbrado
> este cliente contaba con sucursales por todo el pais y necesitaba un
> software que controle todas sus ventas pedidos y control de almacen (

> necesidad tipica no ? ) pero la diferencia radicaba en que las

> debian conectarse remotamente a un solo servidor de base de datos que se
> ubicaba en la central de la empresa bueno entonces el plan era mudar
> nuestros sistemas ( los clasicos cliente/servidor LAN ) a una

> de 3 capas ( todos mis desarrolladores tienen experiencia en vb6

> y
> por el momento ) . entonces decidimos hacer nuestros dll ( capa de
> negocio ) en visual basic 6 porque no nos quedaba otra
> no habia tiempo para investigar otros lenguajes y seguimos algunas

> recomendadas por n libros que encontramos que serian las siguientes :
>
> LAS MEDIDAS DEL CASO
> 1- no utilizar "selects" genericos en los llamados a la capa de datos

> decir no utilizar tanto "*" y etc
>
> 2- no pasar objetos a las funciones o procedimientos que contienen los
> componentes ( objetos como un recordset por ejemplo )
> ( esta norma la tenemos en cuenta sin embargo aun no la estamos

> porque en nuestros desarrolladores se ha vuelto algo adictivo pasarle
> recordsets al
> componente lo hace mas sencillo segun comentan todos )
>
> 3- traer la informacion desde la capa de datos , trabajarla localmente

> la capa de presentacion ( hecha en vb6 naturalmente ) , y luego

> los cambios
> locales y transferirlos al servidor de base de datos ( capa de datos )
> esto
> lo realizamos con el metodo Save que tiene el Recordset de ado y graba

> recordsets a disco duro ( tampoco sabemos si esta tecnica es : bien

> ?, es comunmente usada ?, es pesima ? , o es un standard ) pero lo que
> nosotros si sabemos es que nos ayuda en la capa de presentacion
> tremendamente .
>
> 4- estamos programando todas las reglas de negocio y validaciones en

> componentes dlls es decir estamos tratando de programar al estilo 3

> y
> pensar de
> esa manera
>
> 5- utilizamos la politica de conectarnos (pasando la cadena de conexion
> osea
> un string como parametro) luego ejecutar las tareas en el sqlserver
> y automaticamente nos desconectamos claro esto tiene que ver con el
> punto
> de los recordsets y el metodo "SAVE" del mismo
>
> 6- la capa de presentacion no tiene ninguna relacion con sql server solo
> los
> componentes se comunican con el
>
> 7- aun no hemos utilizado el objeto contexto y agrupar procesos en un

> contexto ( para no complicar la cosa )
>
> 8- bueno si utilizamos commit y rollbacks en la comunicacion con la

> de datos
>
> ..Y BUENO esa son todas las precauciones y criterios que hemos seguido
> para
> hacer el modelo de 3 capas AHORA LES DESCRIBO :
>
>
> LAS DUDAS ,MITOS , TEMORES Y PROBLEMAS
> "el gran problema" ya estan rediseñadas todas mis aplicaciones bajo

> programacion que he descrito pero "HASTA AHORA" NO hemos probado sacar
> los
> dlls de vb6 e instanciarlas en el servidor de componentes de

> no lo podiamos hacer en nuestra misma oficina porque supuestamente
> estabamos
> SOLO en una red de trabajo Lan y conectados a internet via ADSL de
> velocidad basica y sin ningun numero ip ( por lo menos creo que esa era
> la
> razon o la excusa ) . CLARO OBVIAMENTE podiamos probar colgando todos

> componentes en mi servidor de componentes y que por la red local las
> aplicaciones
> reconocieran al servidor y trabaje ( pero esto no probaria la

> del viaje REAL de la informacion por internet que es lo que nos interesa
> ahora )
> ahora nos queda 7 dias para la primera entrega y van a querer hacer
> pruebas
> conectando las sucursales y nosotros no tenemos idea de que va a ocurrir
> :(
> AHORA IMAGINATE EN EL PROBLEMA QUE ESTOY !! ahora he subdividido mis
> interrogantes el que sepa alguna o todas en serio ...GRACIAS :
>
> 0) me doy un balazo en la cabeza ? ( no verdad ? ) :)
>
>
> 1) me falto alguna consideracion importante en la programacion de
> componentes ? o algo para mejorar la performance via remota ? o lo hice
> todo
> mal ? , tengo que
> hacer algun seteo importante al momento de compilar la dll de vb6
> aparte
> de la compatibilidad binaria y la propiedad Multiuse ?
>
> 2) Cual seria la configuracion mas adecuada de mis componentes ? ( estoy
> hablando del seteo que se realiza en el component manager )
> tenemos los temas del < JIT , colas de componentes , colas de

> , hilo simple y multihilo ( que no entendi bien) , agrupacion de
> conexiones
> , agrupacion de objetos , compatibilidad con transaccion , apodos ,
> eventos
> com+ > y n temas diversos que me hicieron entender muchas cosas y

> la
> vez confundirme o agarrarle respeto a todo esto PERO mis componentes

> simples , en contadas oportunidades uno de mis componentes llama a otro
> componente , con las justas los metodos de un mismo componente se llaman
> entre si , esto para evitar excentricidades en los seteos y bueno si
> quieren
> saber sobre la carga de trabajo que tendran los componentes pues tendran
> unas 15 sucursales conectandose con la central al mismo tiempo en total

> emitiran 100 documentos de venta diario entre todas las sucursales lo

> en
> realidad no me parece exagerado ( POR LO MENOS NO LO ERA EN
> CLIENTE/SERVIDOR LAN )
>
> 3) conversando con amigos administradores de red he capturado algunas
> opiniones que me han hecho entrar en panico algunos dicen que :
> - no se puede utilizar un servidor COM+ si no tienes un ip publico

> que me parece algo logico ? o no ?
> - es una burla total tratar de implementar COM+ con ADSL en el
> servidor de componentes y en el servidor de datos aunque tengan ip
> publicos
> que lo mejor es tener linea dedicada si se quiere hacer algo serio
> ( cuando se enteren de esto mi cliente me van a crucificar !!! )
> - que se necesita de 512 kb de transferencia para trabajar ok (

> entonces seria una velocidad aceptable ? con la carga que he descrito

>
> 4) algunos libros y programadores de visual C dicen que realizar
> componentes en visual basic 6 no es recomendable que es mejor hacerlos

> visual c pero en ningun lado cuentan PORQUE o que es lo que visual

> como componente NO HACE !!! ???????????????
>
> 5) una vez que sigo los pasos del "asistente para la exportacion de
> aplicaciones COM" solo tengo que llevar ese instalador a las maquinas de
> las
> sucursales
> instalarlo alli y problema solucionado ? o es que tengo que poner a
> esas maquinas remotas "NECESARIAMENTE" en el mismo dominio y que las
> sucursales se logeen al windows server de la central ? ( actualmente

> sucursales solo son maquinas con internet no tienen ninguna relacion ni
> dependencia con la central )
> necesito saber como debo configurar las maquinas remotas
>
> 6) creo que sera necesario utilizar la agrupacion de conexiones del
> odbcad32 en el server bueno supongo ?
>
> 7) porque consultando algunos dicen que no hay nada mejor que hacer la
> capa
> de presentacion en ASP ? es porque la capa cliente estaria mas cerca al
> servidor de
> base de datos ? ( esto si se supone que IIS , ms com manager , y sql
> server estan todos en una LAN ) o existe otra razon ? al final los

> estan instanciando el
> mismo com+ asi que aparte de lo descrito la velocidad y performance
> deberia ser la misma
>
> Colegas Me quedan 7 dias ( esto paso de ser el señor de los anillos
> a
> "THE RING" ) espero poder hacerle un fix a todo lo que he hecho
> para que pueda caminar y escoger la mejor solucion de infraestructura
> para
> la comunicacion .
>
>
>
> OTRA VEZ GRACIAS POR LEERLO .
>
>