Ayuda sobre Servicios Web

07/04/2008 - 15:55 por Juan Diego Bueno | Informe spam

Buenas gente:

Estoy inmerso en un proyecto de aplicación distribuida, la cual consta
de un servidor central con una BD central, y una serie de bases de
datos distribuidas en cada uno de los nodos.

La idea, como cabría de esperar, es montar un sistema de réplica
controlado entre el servidor central y los nodos. Se trata de poder
enviar y recibir datos de central a nodo y de nodo a central. Mi
primera idea, básicamente por mis conocimientos actuales, es usar
WebServices. En principio, no tengo mayor problema para hacer lo que
hago, pero me preocupa una cuestión: El WS envía archivos XML con los
registros y el esquema de documento por cada tabla que importo o
exporto. El tema es que estos nodos están en movimiento y en algún
momento han de tener que conectarse vía satélite o móvil. En estos
casos, se suele facturar por la tasa de transferencia de datos y por
ello es necesario que estos sean lo menor posible. Y he aquí mi duda:

¿Puedo de alguna manera comprimir o minimizar este envío y recepción de
datos con WS/XML?
¿Debo pensar en alguna otra posibilidad que me garantice que los datos
que se envían son mímimos? Y de ser así ¿qué más opciones tengo?

Gracias de antemano. Un saludo

http://www.moondance.tk

Siga el debate

19 respuestas

Tengo una respuesta

Preguntas similare

Leer las respuestas

#11 Alfredo Novoa

07/04/2008 - 18:35 | Informe spam

Hola Juan Diego,

On Mon, 7 Apr 2008 09:28:57 -0700 (PDT), Juan Diego Bueno
wrote:

¿Esto no me requiere mucho tiempo de desarrollo?. Estoy hablando de
replicar unas 100 tablas con sus correspondientes campos y tipos...

Hombre, habría que hacer un par de rutinillas que leyesen y
escribiesen cualquier DataTable, no lo vas a hacer 100 veces :-)

Estoy suponiendo que se mandan a cascoporro cada uno de los registros
y luego de ahí tengo que extraer sus campos y traducirlos a la
estructura propia de la tabla. Desde luego, a nivel de información, se
manda la justa, pero me da que esto lleva mucho tiempo implementarlo.

¿Más de media tarde? Yo creo que no.

Casi me convence más usar System.IO.Compression

Es que habría que usar las dos cosas.

Saludos

Responder a este mensaje

#12 Alfredo Novoa

07/04/2008 - 18:53 | Informe spam

Hola Jesús,

On Mon, 7 Apr 2008 18:03:19 +0200, "Jesús López"
wrote:

3) Montártelo tú mismo. Esto no te lo recomendaría porque requiere un
esfuerzo de desarrollo tremendo.

Jolines, si esto es un esfuerzo tremendo entonces algo que le lleve
más de un par de días a una persona es la rehostia :-)

a) Usar WCF. Con WCF podrías tener serialización binaria. No hace falta
que te vayas a .NET Remoting

Esto puede ser una opción interesante. Aun no lo he probado, así que
no se si puede ser eficiente o no.

e) Utilizar sockets. Esto sería la peor locura de todas cuando tienes
WCF que admite el protocolo TCP/IP.

¡Pero hombre!, hay muchos tipos de protocolos y unos van por encima de
otros. .NET Remoting tambien va por TCP/IP, y los Web Services con XML
también. El caso es si los datos se transmiten de forma eficiente y
por ejemplo el BinaryFormatter que usa Remoting es bastante
ineficiente.

Saludos

Responder a este mensaje

#13 Alfredo Novoa

07/04/2008 - 18:57 | Informe spam

On Mon, 7 Apr 2008 09:28:57 -0700 (PDT), Juan Diego Bueno
wrote:

¿Esto no me requiere mucho tiempo de desarrollo?. Estoy hablando de
replicar unas 100 tablas con sus correspondientes campos y tipos...

Mira, buscando un poco seguro que encuentras cosas ya hechas:

http://www.codeproject.com/KB/cs/Ra...lizer.aspx

Aquí hay un serializador que dice que es mucho más eficiente que el de
Remoting.

"The BinaryFormatter is a horribly inefficient beast for transmitting
data. It creates a large "binary" file and it sucks up huge amounts of
memory because it isn't a stream, and it can crash your application.
For example, a typical use is to package up the contents of a
DataTable:

"

Saludos
Alfredo

Responder a este mensaje

#14 Jesús López

07/04/2008 - 20:10 | Informe spam

Ningún problema. Los subscriptores pueden ser SQL Server Express o SQL
Server Compact y por supuesto SQL Server Standard, Workgroup y Enterprise.

Saludos:

Jesús López
www.solidq.com

"Juan Diego Bueno" escribió en el mensaje
news:

On 7 abr, 18:17, "Jesús López"
wrote:

Por cierto, la sincronización puede lanzarla perfectamente la aplicación
cliente. Para ello podría lanzar el agente de mezcla o utilizar la
librería
de objetos RMO (Replication Management Objects) presente en SQL Server
2005.

Vale, que no lo había leído al mandar el post :)

Por cierto, los subscriptores son SQL Express, espero que no haya
problema por ello.

Saludos

Responder a este mensaje

#15 Jesús López

07/04/2008 - 20:13 | Informe spam

"Alfredo Novoa" escribió en el mensaje
news:

Hola Jesús,

On Mon, 7 Apr 2008 18:03:19 +0200, "Jesús López"
wrote:

3) Montártelo tú mismo. Esto no te lo recomendaría porque requiere un
esfuerzo de desarrollo tremendo.

Jolines, si esto es un esfuerzo tremendo entonces algo que le lleve
más de un par de días a una persona es la rehostia :-)

Si montas un sistema de replicación y/o sincronización en un par de días me
quito el sombrero :-).

Microsoft tiene un equipo de varias personas sólo para el tema de
replicación en SQL Server y para el Microsoft Synchonization Services
también y ya llevan meses trabajando en él y todavía está en CTP2.

a) Usar WCF. Con WCF podrías tener serialización binaria. No hace
falta
que te vayas a .NET Remoting

Esto puede ser una opción interesante. Aun no lo he probado, así que
no se si puede ser eficiente o no.

Es como todo. Si lo usas bien, será eficiente, si lo usas mal se arrastrará.

e) Utilizar sockets. Esto sería la peor locura de todas cuando tienes
WCF que admite el protocolo TCP/IP.

¡Pero hombre!, hay muchos tipos de protocolos y unos van por encima de
otros. .NET Remoting tambien va por TCP/IP, y los Web Services con XML
también. El caso es si los datos se transmiten de forma eficiente y
por ejemplo el BinaryFormatter que usa Remoting es bastante
ineficiente.