[SyncComm] Componentes WCF de comunicación para Sync Services for ADO.NET for devices

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. 

Para el uso de WCF en .NET Compact Framework, el equipo de desarrollo de Microsoft Sync Framework publicó en su blog unos trucos para la configuración de este tipo de aplicaciones. En dicho post se describen los puntos que se han de seguir para la correcta exposición de un proveedor remoto en WCF.

A partir de esa idea, empecé a desarrollar unas librerías de forma que pudieran ser reutilizadas y sirvieran, a su vez, como punto de partida para todos aquéllos interesados en este tipo de aplicaciones. Dichas librerías se encuentran bajo el proyecto SyncComm y pueden ser descargadas, código abierto, desde CodePlex.

SyncComm es un proyecto que cuenta además con la colaboración de Cesar Fong y el cual pretende ser un punto de partida, como dije anteriormente, para el desarrollo de soluciones de sincronización para dispositivos móviles. Este proyecto viene acompañado de una aplicación muy básica de ejemplo y por el momento SyncComm está en fase Beta, esperando poder aportar otras características interesantes como la seguridad o la gestión de excepciones, entre otras. Seguiremos informando. ;-))

 

SyncComm [http://synccomm.codeplex.com]

Purposes

SyncComm is intended to be used as starter point with Sync Services for ADO.NET 1.0 for devices. SyncComm shows how to implement the WCF communication layer based on Microsoft Sync Framework team’s tips. See: http://blogs.msdn.com/sync/archive/2008/07/14/using-wcf-for-communcation-in-a-mobile-sync-application.aspx

Technologies

Related Resources

SyncComm: Projects descriptions

Basically, SyncComm has two projects for both client (WCF Service Proxy) and server (WCF Service) sides. Moreover, a Service Host Console for hosting WCF Service, DbServerSyncProvider demo project and Windows Forms application for Windows Mobile 5.0 is provided (it also works over Windows Mobile 6.0, Windows Mobile 6.1 and Windows Mobile 6.5).
SyncComm.png
Image1.- SyncComm architecture

SyncComm projects

  • SyncComm.Services: contains the WCF Service definition (ISyncService) needed for any solution based on n-tier Sync Services for ADO.NET. This project may be used for your own project by adapting remote provider application class to your database schema and requirements. (See Customizing SyncComm components for your own project below)
  • SyncComm.Services.Host: hosts WFC Service into basic Console application. It could be replaced by either IIS, WinForms app, Windows Service or WAS.
  • SyncApp.RemoteProvider: This project contains the remote sync provider class for SQL Server database sample as well as AppRemoteProvider helper class that simplify DBRemoteProvider extended class. However, the purpose of this class is to get familiarized with this kind of solution. Is strongly recommended you use your own approach according to Microsoft guidelines you would find on Sync Service for ADO.NET 1.0 SP1 library.
  • GZipEncoder: Optional. Not provided within SyncComm. Necessary for WCF Compression. See Related Resources above.

SyncApp projects

  • SyncComm.Mobile: This class library (targeted on Windows Mobile 5.0 SDK) contains WCF Service proxy class. It could be used in others projects as is, without additional modifications whether no changes are applied on SyncComm.Service.ISyncService service contract.
  • AppMobileSync: This Windows Form Application consumes the WCF Service through such proxy exposed in SyncComm.Mobile. This application demonstrates how to hand a couple of sync tables in bidirectional and uploadonly modes.
  • Microsoft.Samples.Indigo.GzipEncoder: Optional. Not provided within SyncComm. Necessary for WCF Compression. See Related Resources above

Database

Database schema used in this project is based on script you would find in Microsoft Sync Framework “How to’s” library’s topics. It only contains a couple of tables for demonstrating bidirectional and uploadonly sync modes.
Note that three database four files are provided within SyncApp.RemoteProvider project.

  • database schema.sql: Creates a database named wcfSyncSamplesDb, and a couple of tables named Sales.Customer and Sales.CustomerContact.
  • enablingChangeTracking.sql: These scripts enable Change Tracking for wcfSyncSamplesDB database and for Sales.Customer and Sales.CustomerContact with default 2 days retention.
  • enablingCustomTracking.sql: Configures both tables in order to provide a custom change tracking for non SQL Server 2008 data providers.
  • testData.sql: Populates Sales.Customer and Sales.CustomerContact tables.

Setting up solution

For getting started the solution you may follow next steps.

  1. Create database and database objects. Execute database file scripts in the following order.
    1. Execute database schema.sql for creating database and objects.
    2. Execute either enablingChangeTracking.sql or enablingCustomTracking.sql depending on what change tracking type your application will run at.
      1. enablingChangeTracking.sql for SQL Server 2008.
      2. enablingCustomTracking.sql for others.
    3. Populate Sales.Customer after change tracking is enabled by executing testData.sql.
  2. Change database connection string on SyncApp.RemoteProvider -> Settings.settings. (See Image 2)
  3. Set your local IP/host name in app.config file from SyncComm.Service.Host project. (See Code 1)
  4. If you wish to use Compression make sure both client and server related GZipEncoder project are referenced.
  5. Set ISyncServices base endpoint address up in AppMobileSync project. (See Code 2 Method SyncNow in Form1.cs)
  6. Recall to cradle your emulator/device and make sure it reaches endpoint address from IEMobile. Configure your Windows Firewall appropriately for enabling incoming calls for specified port. (Default port 9999). This also could be useful http://msdn.microsoft.com/en-us/library/ms733768.aspx
  7. Execute both SyncComm.Service.Host and AppMobileSync apps. (See Image 4)

ProjProperties.png
Image 2.- Database Connection String

      <service behaviorConfiguration="ISyncServiceBehavior" name="SyncComm.Service.SyncService">
<endpoint address="Basic" binding="basicHttpBinding" name="BasicEndPoint"
contract="SyncComm.Service.ISyncService" />
<endpoint
address ="/GZip"
binding="customBinding"
bindingConfiguration="BufferedHttpSampleServer"
bindingName="BufferedHttpSampleServer"
contract="SyncComm.Service.ISyncService"/>
<host>
<baseAddresses>
<!-- Set here Service Host name/IP -->
<add baseAddress="http://10.0.2.15:9999/SyncService" />
</baseAddresses>
</host>
</service>
</services>

Code 1.- app.config file from SyncComm.Service.Host project.

// Create a CustomBinding
var customBinding = new CustomBinding();
// Create a compression binding element
var compressionBindingElmnt = new CompressionMessageEncodingBindingElement();
// ..and add to the custom binding
customBinding.Elements.Add(compressionBindingElmnt);

// Create an HttpTransportBindingElement and add that as well
var httpBindingElement =
new HttpTransportBindingElement();
customBinding.Elements.Add(httpBindingElement);
// Set WCF Service hosted name/IP endpoint *here*
var endPoint = new EndpointAddress("http://10.0.2.15:9999/SyncService/GZip");

Code 2.- Method SyncNow in Form1.cs
ServiceHost.jpg
Image 4.- Service Host Console Application

Customizing SyncComm components for your own project

  1. Configure your database appropriately. Take a look at the following link for further information. http://msdn.microsoft.com/en-us/library/bb726006.aspx NOTE: Modify uspGetNewBatchAnchor Stored Procedure for validating CHANGE_TRACKING_MIN_VALID_VERSION for your own tables._
  2. Create your own Remote Sync Provider class (DBRemoteProvider). Keep in mind sync modes you would need to use for each table. You may use AppRemoteProvider class but is strongly recommended using custom Stored Procedures instead of sentences generated by SyncAdapterBuilder class.
  3. Host SyncService on well-known IP address and pass it on SyncClient class constructor, in the client side. You may use other Service Host platform instead of console app provided by this sample.
  4. If you need to configure binding behavior take in care WCF limitations for .NET Compact Framework.
  5. Refer SyncComm.Mobile.dll assembly from your .NET CF application. Configure SyncAgent at your own discretion but don’t forget to set up the tables with the sync modes you configured on server side before.

IMPORTANT: This sample is provided «as is», without warranty of any kind, express or implied. Suggestions, comments or whatever are welcomed at Discussion Pane

Más Windows Mobile 6.5: el turno para los Widgets!!

Aprovechando la presentación de los emuladores de Windows Mobile 6.5, Jorge Peraza (Microsoft Corp) ha publicado un intersantísimo post sobre el desarrollo de widgets en el blog del equipo de desarrollo de Windows Mobile.

Es importante que sigáis punto por punto lo que explica Jorge y evidentemente sobre los nuevos emuladores de Windows Mobile 6.5. El ejemplo es muy básico pero suficiente para empezar con el desarrollo de este tipo de aplicaciones. Destacar que los widgets son aplicaciones HTML (además de  javascript, XSL,..) y la facilidad de despliegue mediante comprensión de la aplicación en un ZIP.

A disfrutarlo!!!

PD: El enlace al post de Jorge. Gracias José Antonio!!!

Visual Studio 2010 + Windows Mobile + .NET Compact Framework

Tras la tan esperada Beta 1 de Visual Studio 2010 muchos de vosotros habéis podido apreciar que NO existe soporte de proyectos para dispositivos Windows Mobile. Lo cierto es que tras la decepción inicial acompañada de la poca información y ausencia de una postura oficial por parte de Microsoft, ahora sí,  Microsoft  ha publicado de forma oficial en MSDN lo siguiente:

[Traducción del ingés]

«Microsoft está comprometido en hacer de Visual Studio una potente herramienta de desarrollo para el desarrollador de dispositivos móviles,  y por tanto Visual Studio 2010 ofrecerá  soporte para el desarrollo de dispositivos móviles, pero no se pueden ofrecer detalles al respecto, en estos momentos. Para los actuales desarrolladores de dispositivos móviles en Visual Studio 2008, Microsoft ofrecerá un emulador de Windows Mobile 6.5 que trabajará junto a los existentes SDK de Windows Mobile 6.»

Mola ¿no? 😉