Es conveniente Usar Dataset como Contenedor de Datos para un Entorno Cliente Servidor???

En ese caso yo montaría una replicación transacional con colas o una
replicación de mezcla en SQL Server ya que es un escenario muy típico para
replicación. Por otra parte crearía aplicaciónes Windows que accedieran al
SQL Server local, nada de servicios web ni COM+.

El publicador y distribuidor de la replicación sería el servidor SQL Server
central y los MSDE 2000 de las oficinas serían los subscriptores.

Tanto en replicación transacional con colas como en la replicación de mezcla
puede tenerse un retraso en la actualización de los datos muy pequeño y en
los dos casos se puede seguir trabajando normalmente aunque falle la
conexión a internet. Para mayor seguridad sería recomendable montar una red
privada virtual, aunque esto no es necesario porque la replicación de mezcla
puede sincronizarse por IIS usando el protocolo HTTPS.

Saludos

Jesús López
MVP


"Developers" escribió en el mensaje
news:

Contesto entre Lineas

Jesús López escribió:

Me faltaría alguna información para dar una respuesta más a medida.

¿Cómo están interconectadas las oficinas?.

Actualmente No estan interconectadas entre si, la comunicación es Via
Email.

¿Todas las oficinas tienen conexión de banda ancha a Internet?

Todas las Oficinas estan Usando Internet Banda Ancha

¿Cómo están distribuidos los datos? ¿Las oficinas tienen sus propios
datos en su propio SQL Server local?

Cada Oficina Tiene su Data Trabajada en Msde2000 y la Prinpal cuenta con
Sql Server 2000 Standar, pero necesita que la Data que ellos tienen
tambien tenga la oficina Principal (Cualquier Cambio que exista de
Informacion debe estar reflejada en la Principal pero si la Principal hace
Su cierre Mensual las demas Oficinas No podran tocar esa información mas
que verla solamente.
La principal solicita que la información sea Reflejada en Cualquier
Momento (NO quieren Información Actualizada al Final del Dia)

¿De cuantos usuarios estaríamos hablando?

Ahorita de 70 Usuarios pero puede seguir creciendo

Dependiendo de las respuestas a estas preguntas, la arquitectura más
adecuada sería distinta. Hay varias opciones:

(1) Replicación. Tener SQL Server locales que son subscriptores de una
publicación del Servidor SQL Server central. Las aplicaciones sólo
tendrían que acceder al servidor local. Los servidores locales podrían
ser incluso MSDE 2k o SQL Server 2005 Express. Esta arquitectura tiene
la ventaja de que las oficinas podrían seguir trabajando incluso cuando
se perdiera la conexión a Internet.

(2) Un único servidor SQL Server central. Las aplicaciones cliente
accederían a un servicio web de la oficina central o a COM+ o a .NET
Remoting . Sin embargo COM+ sólo sería una opción viable si las oficinas
estuvieran interconectadas por una red dedicada o mediante una VPN por
Internet. Además COM+ es engorroso de desplegar y la gestión de versiones
no es tarea trivial. Así que web services sería seguramente la opción más
deseable.


En cuanto a usar DataSets o no, yo particularmente pienso que los
datasets definidos (strong typed) son una buena opción en la mayoría de
los casos. La alternativa, que sería usar objetos de negocio, que no son
más que clases que mapean sus propiedades con campos de la base de datos,
son más livianos que los DataSets. Pero la ligereza de los objetos de
negocio tiene un precio que es un mayor tiempo de desarrollo y una menor
funcionalidad. Los datasets tienen capacidades de filtrado, ordenación y
búsqueda, enlace a controles y soporte para la gestión optimista de la
concurrencia. Para los objetos de negocio habría que escribir un montón
de código para dotarles de esta funcionalidad y si se hace así, entonces
se pierde su ligereza y además terminan pareciéndose mucho a los datasets
definidos. Por estas razones, yo personalmente prefiero usar Datasets
definidos desde el principio, en la mayoría de los casos su pesadez
comparada con la ligereza de los objetos de negocio no supone una pérdida
de rendimiento lo suficientemente apreciable como para ser considerada.

Si te decides por usar servicios web. Hay un par de recomendaciones que
se deberían seguir:

(1) Usar dataset definidos. Es conveniente que las aplicaciones cliente
conozcan el esquema de los datasets usados. Usando datasets definidos el
esquema está presente en el documento WSDL del servicio web.
(2) Usar DataSet.GetChanges(). A la hora de guardar los datos, las
aplicaciones cliente deberían enviar sólo los cambios, no el dataset
entero. Esto reduce el tráfico de red y el procesamiento en el servidor
web.
(3) Usar Dataset.SchemaSerializationMode = ExcludeSchema. Si las
aplicaciones ya conocen el esquema de los dataset, no hay razón alguna
para enviar el esquema cada vez que se envia un dataset. Esto reduce el
tráfico de red
(4) Comprimir el tráfico HTTP. El servidor web, puede comprimir todo el
tráfico HTTP de salida. Esto aumenta bastante el rendimiento de las
aplicaciones al reducir considerablemente el tráfico de red. En este blog
se explica como configurar IIS 6.0 para que comprima el tráfico HTTP:
http://weblogs.asp.net/owscott/arch...57916.aspx . El proxy
del cliente tendría que tener la propiedad EnableDecompression = True.
Lástima que no haya compresión automática de los datos que van desde el
cliente al servidor. Sin embargo esto puede conseguirse mediante
extensiones soap.


NOTA: las recomendaciones (3) y (4) sólo están disponibles en .NET
Framework 2.0. En .NET Framework 1.1 se puede conseguir compresión en los
dos sentidos usando extensiones soap.

Saludos:

Jesús López
MVP


"Developers" escribió en el mensaje
news:

Amigos estoy a punto de iniciar un Proyecto en VB.Net 2003(Puede ser
2005)+ SQL2000 bajo entorno Cliente/Servidor(Capas Datos+Capa
Logicas+Interfaces+Interconexion de Oficinas de Todo el Pais), pero mi
duda es lo siguientes:

Es conveniente Trabajar con Dataset toda la aplicacion bajo este entorno
o Solamente usar Dataset cuando sean necesarios(Reportes,algunas
Consultas)???

Eso influira en el Rendimiento de la aplicación Local / Remoto??

Para Trabajar con Data Interconectada en todo el Pais es conveniente
Trabajar con WebServices o que la Aplicacion pueda usar Directamente Com+
de la Central???


ojala me puedan orientar y sacarme algunas dudas...

Gracias

Developers - Dany Acosta

Amigo tendras algunos links de donde poder obtener información de como
realizar esto en SqlServer.
Ya que seria mi Primera Aventura respecto a esto.

Gracias



Jesús López escribió:

En ese caso yo montaría una replicación transacional con colas o una
replicación de mezcla en SQL Server ya que es un escenario muy típico
para replicación. Por otra parte crearía aplicaciónes Windows que
accedieran al SQL Server local, nada de servicios web ni COM+.

El publicador y distribuidor de la replicación sería el servidor SQL
Server central y los MSDE 2000 de las oficinas serían los subscriptores.

Tanto en replicación transacional con colas como en la replicación de
mezcla puede tenerse un retraso en la actualización de los datos muy
pequeño y en los dos casos se puede seguir trabajando normalmente aunque
falle la conexión a internet. Para mayor seguridad sería recomendable
montar una red privada virtual, aunque esto no es necesario porque la
replicación de mezcla puede sincronizarse por IIS usando el protocolo
HTTPS.

Saludos

Jesús López
MVP


"Developers" escribió en el mensaje
news:

Contesto entre Lineas

Jesús López escribió:

Me faltaría alguna información para dar una respuesta más a medida.

¿Cómo están interconectadas las oficinas?.

Actualmente No estan interconectadas entre si, la comunicación es Via
Email.

¿Todas las oficinas tienen conexión de banda ancha a Internet?

Todas las Oficinas estan Usando Internet Banda Ancha

¿Cómo están distribuidos los datos? ¿Las oficinas tienen sus propios
datos en su propio SQL Server local?

Cada Oficina Tiene su Data Trabajada en Msde2000 y la Prinpal cuenta con
Sql Server 2000 Standar, pero necesita que la Data que ellos tienen
tambien tenga la oficina Principal (Cualquier Cambio que exista de
Informacion debe estar reflejada en la Principal pero si la Principal
hace Su cierre Mensual las demas Oficinas No podran tocar esa información
mas que verla solamente.
La principal solicita que la información sea Reflejada en Cualquier
Momento (NO quieren Información Actualizada al Final del Dia)

¿De cuantos usuarios estaríamos hablando?

Ahorita de 70 Usuarios pero puede seguir creciendo

Dependiendo de las respuestas a estas preguntas, la arquitectura más
adecuada sería distinta. Hay varias opciones:

(1) Replicación. Tener SQL Server locales que son subscriptores de una
publicación del Servidor SQL Server central. Las aplicaciones sólo
tendrían que acceder al servidor local. Los servidores locales podrían
ser incluso MSDE 2k o SQL Server 2005 Express. Esta arquitectura tiene
la ventaja de que las oficinas podrían seguir trabajando incluso cuando
se perdiera la conexión a Internet.

(2) Un único servidor SQL Server central. Las aplicaciones cliente
accederían a un servicio web de la oficina central o a COM+ o a .NET
Remoting . Sin embargo COM+ sólo sería una opción viable si las oficinas
estuvieran interconectadas por una red dedicada o mediante una VPN por
Internet. Además COM+ es engorroso de desplegar y la gestión de
versiones no es tarea trivial. Así que web services sería seguramente la
opción más deseable.


En cuanto a usar DataSets o no, yo particularmente pienso que los
datasets definidos (strong typed) son una buena opción en la mayoría de
los casos. La alternativa, que sería usar objetos de negocio, que no son
más que clases que mapean sus propiedades con campos de la base de
datos, son más livianos que los DataSets. Pero la ligereza de los
objetos de negocio tiene un precio que es un mayor tiempo de desarrollo
y una menor funcionalidad. Los datasets tienen capacidades de filtrado,
ordenación y búsqueda, enlace a controles y soporte para la gestión
optimista de la concurrencia. Para los objetos de negocio habría que
escribir un montón de código para dotarles de esta funcionalidad y si se
hace así, entonces se pierde su ligereza y además terminan pareciéndose
mucho a los datasets definidos. Por estas razones, yo personalmente
prefiero usar Datasets definidos desde el principio, en la mayoría de
los casos su pesadez comparada con la ligereza de los objetos de negocio
no supone una pérdida de rendimiento lo suficientemente apreciable como
para ser considerada.

Si te decides por usar servicios web. Hay un par de recomendaciones que
se deberían seguir:

(1) Usar dataset definidos. Es conveniente que las aplicaciones cliente
conozcan el esquema de los datasets usados. Usando datasets definidos el
esquema está presente en el documento WSDL del servicio web.
(2) Usar DataSet.GetChanges(). A la hora de guardar los datos, las
aplicaciones cliente deberían enviar sólo los cambios, no el dataset
entero. Esto reduce el tráfico de red y el procesamiento en el servidor
web.
(3) Usar Dataset.SchemaSerializationMode = ExcludeSchema. Si las
aplicaciones ya conocen el esquema de los dataset, no hay razón alguna
para enviar el esquema cada vez que se envia un dataset. Esto reduce el
tráfico de red
(4) Comprimir el tráfico HTTP. El servidor web, puede comprimir todo el
tráfico HTTP de salida. Esto aumenta bastante el rendimiento de las
aplicaciones al reducir considerablemente el tráfico de red. En este
blog se explica como configurar IIS 6.0 para que comprima el tráfico
HTTP: http://weblogs.asp.net/owscott/arch...57916.aspx . El
proxy del cliente tendría que tener la propiedad EnableDecompression =
True. Lástima que no haya compresión automática de los datos que van
desde el cliente al servidor. Sin embargo esto puede conseguirse
mediante extensiones soap.


NOTA: las recomendaciones (3) y (4) sólo están disponibles en .NET
Framework 2.0. En .NET Framework 1.1 se puede conseguir compresión en
los dos sentidos usando extensiones soap.

Saludos:

Jesús López
MVP


"Developers" escribió en el mensaje
news:

Amigos estoy a punto de iniciar un Proyecto en VB.Net 2003(Puede ser
2005)+ SQL2000 bajo entorno Cliente/Servidor(Capas Datos+Capa
Logicas+Interfaces+Interconexion de Oficinas de Todo el Pais), pero mi
duda es lo siguientes:

Es conveniente Trabajar con Dataset toda la aplicacion bajo este
entorno o Solamente usar Dataset cuando sean
necesarios(Reportes,algunas Consultas)???

Eso influira en el Rendimiento de la aplicación Local / Remoto??

Para Trabajar con Data Interconectada en todo el Pais es conveniente
Trabajar con WebServices o que la Aplicacion pueda usar Directamente
Com+ de la Central???


ojala me puedan orientar y sacarme algunas dudas...

Gracias

Developers - Dany Acosta

Los libros en pantalla de SQL Server 2000 te explican todo lo referente a
replicación y mucho más. Te recomendaría que leyeras la documentación,
hicieras todas las pruebas habidas y por haber y preguntaras en el grupo
microsoft.public.es.sqlserver todas las dudas que te vayan surgiendo.

De aquí puedes descargar los libros en pantalla de SQL Server 2000:

http://www.microsoft.com/downloads/...p;FamilyID¦f79cb1-a420-445f-8a4b-bd77a7da194b

Saludos:

Jesús López



"Developers" escribió en el mensaje
news:

Amigo tendras algunos links de donde poder obtener información de como
realizar esto en SqlServer.
Ya que seria mi Primera Aventura respecto a esto.

Gracias



Jesús López escribió:

En ese caso yo montaría una replicación transacional con colas o una
replicación de mezcla en SQL Server ya que es un escenario muy típico
para replicación. Por otra parte crearía aplicaciónes Windows que
accedieran al SQL Server local, nada de servicios web ni COM+.

El publicador y distribuidor de la replicación sería el servidor SQL
Server central y los MSDE 2000 de las oficinas serían los subscriptores.

Tanto en replicación transacional con colas como en la replicación de
mezcla puede tenerse un retraso en la actualización de los datos muy
pequeño y en los dos casos se puede seguir trabajando normalmente aunque
falle la conexión a internet. Para mayor seguridad sería recomendable
montar una red privada virtual, aunque esto no es necesario porque la
replicación de mezcla puede sincronizarse por IIS usando el protocolo
HTTPS.

Saludos

Jesús López
MVP


"Developers" escribió en el mensaje
news:

Contesto entre Lineas

Jesús López escribió:

Me faltaría alguna información para dar una respuesta más a medida.

¿Cómo están interconectadas las oficinas?.

Actualmente No estan interconectadas entre si, la comunicación es Via
Email.

¿Todas las oficinas tienen conexión de banda ancha a Internet?

Todas las Oficinas estan Usando Internet Banda Ancha

¿Cómo están distribuidos los datos? ¿Las oficinas tienen sus propios
datos en su propio SQL Server local?

Cada Oficina Tiene su Data Trabajada en Msde2000 y la Prinpal cuenta con
Sql Server 2000 Standar, pero necesita que la Data que ellos tienen
tambien tenga la oficina Principal (Cualquier Cambio que exista de
Informacion debe estar reflejada en la Principal pero si la Principal
hace Su cierre Mensual las demas Oficinas No podran tocar esa información
mas que verla solamente.
La principal solicita que la información sea Reflejada en Cualquier
Momento (NO quieren Información Actualizada al Final del Dia)

¿De cuantos usuarios estaríamos hablando?

Ahorita de 70 Usuarios pero puede seguir creciendo

Dependiendo de las respuestas a estas preguntas, la arquitectura más
adecuada sería distinta. Hay varias opciones:

(1) Replicación. Tener SQL Server locales que son subscriptores de una
publicación del Servidor SQL Server central. Las aplicaciones sólo
tendrían que acceder al servidor local. Los servidores locales podrían
ser incluso MSDE 2k o SQL Server 2005 Express. Esta arquitectura tiene
la ventaja de que las oficinas podrían seguir trabajando incluso cuando
se perdiera la conexión a Internet.

(2) Un único servidor SQL Server central. Las aplicaciones cliente
accederían a un servicio web de la oficina central o a COM+ o a .NET
Remoting . Sin embargo COM+ sólo sería una opción viable si las oficinas
estuvieran interconectadas por una red dedicada o mediante una VPN por
Internet. Además COM+ es engorroso de desplegar y la gestión de
versiones no es tarea trivial. Así que web services sería seguramente la
opción más deseable.


En cuanto a usar DataSets o no, yo particularmente pienso que los
datasets definidos (strong typed) son una buena opción en la mayoría de
los casos. La alternativa, que sería usar objetos de negocio, que no son
más que clases que mapean sus propiedades con campos de la base de
datos, son más livianos que los DataSets. Pero la ligereza de los
objetos de negocio tiene un precio que es un mayor tiempo de desarrollo
y una menor funcionalidad. Los datasets tienen capacidades de filtrado,
ordenación y búsqueda, enlace a controles y soporte para la gestión
optimista de la concurrencia. Para los objetos de negocio habría que
escribir un montón de código para dotarles de esta funcionalidad y si se
hace así, entonces se pierde su ligereza y además terminan pareciéndose
mucho a los datasets definidos. Por estas razones, yo personalmente
prefiero usar Datasets definidos desde el principio, en la mayoría de
los casos su pesadez comparada con la ligereza de los objetos de negocio
no supone una pérdida de rendimiento lo suficientemente apreciable como
para ser considerada.

Si te decides por usar servicios web. Hay un par de recomendaciones que
se deberían seguir:

(1) Usar dataset definidos. Es conveniente que las aplicaciones cliente
conozcan el esquema de los datasets usados. Usando datasets definidos el
esquema está presente en el documento WSDL del servicio web.
(2) Usar DataSet.GetChanges(). A la hora de guardar los datos, las
aplicaciones cliente deberían enviar sólo los cambios, no el dataset
entero. Esto reduce el tráfico de red y el procesamiento en el servidor
web.
(3) Usar Dataset.SchemaSerializationMode = ExcludeSchema. Si las
aplicaciones ya conocen el esquema de los dataset, no hay razón alguna
para enviar el esquema cada vez que se envia un dataset. Esto reduce el
tráfico de red
(4) Comprimir el tráfico HTTP. El servidor web, puede comprimir todo el
tráfico HTTP de salida. Esto aumenta bastante el rendimiento de las
aplicaciones al reducir considerablemente el tráfico de red. En este
blog se explica como configurar IIS 6.0 para que comprima el tráfico
HTTP: http://weblogs.asp.net/owscott/arch...57916.aspx . El
proxy del cliente tendría que tener la propiedad EnableDecompression =
True. Lástima que no haya compresión automática de los datos que van
desde el cliente al servidor. Sin embargo esto puede conseguirse
mediante extensiones soap.


NOTA: las recomendaciones (3) y (4) sólo están disponibles en .NET
Framework 2.0. En .NET Framework 1.1 se puede conseguir compresión en
los dos sentidos usando extensiones soap.

Saludos:

Jesús López
MVP


"Developers" escribió en el mensaje
news:

Amigos estoy a punto de iniciar un Proyecto en VB.Net 2003(Puede ser
2005)+ SQL2000 bajo entorno Cliente/Servidor(Capas Datos+Capa
Logicas+Interfaces+Interconexion de Oficinas de Todo el Pais), pero mi
duda es lo siguientes:

Es conveniente Trabajar con Dataset toda la aplicacion bajo este
entorno o Solamente usar Dataset cuando sean
necesarios(Reportes,algunas Consultas)???

Eso influira en el Rendimiento de la aplicación Local / Remoto??

Para Trabajar con Data Interconectada en todo el Pais es conveniente
Trabajar con WebServices o que la Aplicacion pueda usar Directamente
Com+ de la Central???


ojala me puedan orientar y sacarme algunas dudas...

Gracias

Developers - Dany Acosta