Con un poco de retraso, pues tenia pensado publicar esta versión a principios de agosto, acabo de publicar la nueva versión (0.95) de SyncComm. Como novedades:
- Nueva gestión de excepciones
- Corregidos algunos BUGs
- Mas flexibilidad en el uso de las propiedades de los enlaces para HttpBinding y CompressedBinding.
- Modificados los namespace
Nueva gestión de excepciones
SyncComm aporta una forma de propagación de excepciones en el proceso de sincronización mediante Sync Services for ADO.NET y el proveedor remoto de sincronización expuesto en un servicio WCF. Básicamente, el proxy generado por la herramienta de generación netcfsvcutil.exe y que se utilizó, con algunas modificaciones para llevar a cabo las sincronizaciones, en las versiones iniciales, no procesaba las excepciones o mensajes fault propagados por el servicio WCF. Siguiendo la Guia WCF para desarrolladores Mobile, publicada también en codeplex, mi primer acercamiento fue el de utilizar el proyecto Mobile.ServiceModelEx expuesto por los autores, el cual solucionaba en gran medida toda la gestión de excepciones entre el servicio WCF y el terminal móvil. Sin embargo, únicamente era válido para enlaces cuya versón de mensaje fuera MessageVersion.Soap11, o mejor dicho, la implementación para otras versiones de mensaje no está implementada. El problema es que SyncComm utilitza un enlace con compresión, mediante GZip encoder, y cuya versión de mensaje SOAP es MessageVersion.Soap12WSAddressing10. Después de algunos intentos de comunicación con los autores, todos sin éxito, decidí implementar dicha características para ambas versiones de mensajes SOAP y pese a que no está tan avanzada como Mobile.ServiceModelEx, lo cierto es que cubre los requisitos necesario para la propagación eficiente de cualquier tipo de anomalía durante el proceso de sincronización y la posterior captura y proceso desde el cliente.
Ahora seriamos capaces de propagar mensajes de error desde el servicio WCF de la siguiente forma:
1: catch (SqlException sqlex)
2: {
3: Guid id = Guid.NewGuid();
4:
5: //display detailed exception information on console
6: Notification.Invoke(DateTime.Now,
7: string.Format ("Exception {0}: {1}", id.ToString(), sqlex.Message));
8:
9: //throw and exception for being catch by client
10: throw new FaultException<string>(sqlex.Message, new FaultReason(
11: new FaultReasonText("SQL Server is not available. Please try later.")),
12: FaultCode.CreateSenderFaultCode(id.ToString(), "urn:synccomm.com/2009/07/ISyncService"));
13:
14:
15: }
16: catch (Exception e)
17: {
18: Guid id = Guid.NewGuid();
19:
20: //display detailed exception information on console
21: Notification.Invoke(DateTime.Now,
22: string.Format ("Exception {0}: {1}",id.ToString(),e.Message));
23:
24: throw new FaultException<string>(e.Message, new FaultReason(
25: new FaultReasonText("SyncService unavailable. Contact SyncService support.")),
26: FaultCode.CreateSenderFaultCode(id.ToString(), "urn:synccomm.com/2009/07/ISyncService"));
27:
28: }
Capturarlos desde la aplicación .NET Compact Framework como exepción del tipo CFFaultSyncException, dejando los tipos CommunicationException y Exception, para excepciones relativas a la comunicación y otros tipos de excepciones, respectivamente.
1: catch (CFFaultSyncException faultEx)
2: {
3: Cursor.Current = Cursors.Default;
4:
5: //
6: MessageBox.Show(string.Format("FaultCode: {0}rnFaultReason: {1}rnHasDetail: {2}",
7: faultEx.FaultCode, faultEx.FaultMessage, faultEx.HasDetail));
8: }
9: catch (CommunicationException communicationException )
10: {
11: //is the emulator cradled? does it reach SyncService endpoint?
12: MessageBox.Show(communicationException.Message);
13: }
14: catch (Exception e)
15: {
16: //something is not configured properly
17: MessageBox.Show(e.Message);
18: //HResult -2146233087 maybe database must be reinitialize
19:
20: }
De forma que podemos mostrar un mensaje más amigable por pantalla mientras registramos el error técnico (opcional) para su posterior estudio. Además, todas las excepciones (representadas por la clase CFFaulSyncException) tienen un identificador único (System.Guid) lo cual permite registrar dicha excepción tanto en el servidor como en el cliente:
Si deseáis información más detallada aquí.
Corregidos algunos Bug
Como toda nueva versión, se han corregido varios Bugs, tanto registrados desde el site del proyecto como encontrados durante el proceso de desarrollo. El más significativo es el encontrado en los scripts.sql de generación del esquema de seguimiento de modificaciones para bases de datos que utilizan mecanismos de seguimiento personalizados.
Mas flexibilidad en el uso de las propiedades de los enlaces para HttpBinding y CompressedBinding.
Una de las peticiones de algunos desarrolladores fue la posiblidad de incrementar el tamaño máximo del mensaje, el cual se realiza a través de una de las propiedades del enlace. Como tal, se han creado dos métodos en ClientBase.cs los cuales gestionan todas las propiedades relativas los enlaces de la comunicación con WCF. En el siguiente ejemplo podemos ver uno de ellos. Básicamente se agrupa en un mismo método la forma en la que se va crear el enlace al canal de comunicación expuesto por WCF, de forma que la simple modificación de las propiedades como MaxReceiveMessageSize para el enlace de compresión se concentran en un único método. Lo mismo sucede para el enalce básico mediante HttpBinding.
1: //NOTE:
2: //set compressed endpoint binding custom properties here
3: public static System.ServiceModel.Channels.Binding CreateCompressionBinding()
4: {
5: // Create a CustomBinding
6: var customBinding = new CustomBinding();
7: // Create a compression binding element
8: var compressionBindingElmnt = new CompressionMessageEncodingBindingElement();
9: // ..and add to the custom binding
10: customBinding.Elements.Add(compressionBindingElmnt);
11:
12: // Create an HttpTransportBindingElement and add that as well
13: var httpBindingElement = new HttpTransportBindingElement();
14:
15:
16: //TODO
17: //Set here desired values. Take care to match such values
18: //in app.config in SyncComm host project
19: //max buffer size
20: //httpBindingElement.MaxBufferSize = int.MaxValue;
21: //max received message size
22: //httpBindingElement.MaxReceivedMessageSize = long.MaxValue;
23: //max buffer pool size
24: //httpBindingElement.MaxBufferPoolSize = long.MaxValue;
25:
26: customBinding.Elements.Add(httpBindingElement);
27:
28: return customBinding;
29:
30: }
Por consiguiente y debido a que en versiones anteriores estos objetos se instanciaban desde la aplicación .NET CF Windows Form(AppMobileSync) y ahora han pasado al la librería (también .NET CF) SyncComm.Proxy.dll se ha aprovechado para que la instanacia del objecto SyncComm.Proxy.ServiceClient sea mas sencilla desde AppMobileSync. Ahora únicamente debemos indicar la dirección del EndPoint y su respectivo “tipo de enlace”. Dicho “tipo de enlace” se representa mediante el enumerador:
1: namespace SyncComm.Proxy
2: {
3: /// <summary>
4: /// Specify constants defining which endpoint binding to use
5: /// </summary>
6: public enum BindingType
7: {
8: /// <summary>
9: /// Use basic endpoint binding
10: /// </summary>
11: Basic,
12: /// <summary>
13: /// Use compressed endpoint binding
14: /// </summary>
15: Compressed
16: }
17: }
Y por lo tanto la instancia de un objeto SyncComm.Proxy.ServiceClient será tan sencillo como:
1: //NOTE: For compressed endpoint binding use this
2: var endPoint = new EndpointAddress("http://10.0.2.15:9999/SyncService/GZip");
3: var s = new ServiceClient(endPoint, BindingType.Compressed);
4:
5: //NOTE: For basic endpoint use this
6: var endPoint = new EndpointAddress("http://10.0.2.15:9999/SyncService/Basic");
7: var s = new ServiceClient(endPoint, BindingType.Basic);
En lugar de como se hacía en versiones anteriore:
1: // Create a CustomBinding
2: var customBinding = new CustomBinding();
3: // Create a compression binding element
4: var compressionBindingElmnt = new CompressionMessageEncodingBindingElement();
5: // ..and add to the custom binding
6: customBinding.Elements.Add(compressionBindingElmnt);
7:
8: // Create an HttpTransportBindingElement and add that as well
9: var httpBindingElement =
10: new HttpTransportBindingElement();
11: customBinding.Elements.Add(httpBindingElement);
12: // Set endpoint
13: var endPoint = new EndpointAddress("http://10.0.2.15:9999/SyncService/GZip");
://10.0.2.15:9999/SyncService/GZip");
14: #endregion
15:
16: // Create the WCF proxy using the custom binding
17: var s = new ServiceClient(customBinding,endPoint);
Modificados los namespace
Por último, se han modificado todos los namespace de los contratos WCF que antes eran inexistente. Ahora todos pasan a ser urn:synccomm/07/2009.
Ya es oficial
Dentro de los requisitos que debemos tener en cuenta en el desarrollo de soluciones de sincronización de datos para plataformas Windows Mobile utilizando los servicios Sync Services for ADO.NET 1.0 SP1 se encuentra la comunicación entre el propio dispositivo móvil, donde albergamos tanto el agente de sincronización como el proveedor de sincronización local, y el servidor dónde reside el proveedor de sincronización remoto el cual exponemos a través de un servicio Web o WCF. 
