Options for writing server-side synchronization logic

MobiLink synchronization scripts can be written in SQL, or they can be written in Java (using the MobiLink server API for Java) or in .NET (using the MobiLink server API for .NET).

SQL synchronization logic is usually best when synchronizing to a supported consolidated database.

Java and .NET are useful if you are synchronizing against something other than a supported consolidated database. They may also be useful if your design is restricted by the limitations of the SQL language or by the capabilities of your database management system, or if you simply want portability across different RDBMS types.

Java and .NET synchronization logic can function just as SQL logic functions. The MobiLink server can make calls to Java or .NET methods on the occurrence of MobiLink events just as it can access SQL scripts on the occurrence of MobiLink events. When you are working in Java or .NET, you can use the events to do some extra processing, but when you are processing scripts for events that directly handle upload or download rows, your implementation must return a SQL string. With the exception of the two events used in direct row handling, uploads and downloads are not directly accessible from Java or .NET synchronization logic: MobiLink executes the string returned by Java or .NET as SQL.

Direct row handling, which uses the events handle_UploadData and handle_DownloadData to synchronize against a data source, does directly manipulate the upload and download rows.

Following are some scenarios where you might want to consider writing scripts in Java or .NET:

  • Direct row handling   With Java and .NET synchronization logic, you can use MobiLink to access data from data sources other than your consolidated database, such as application servers, web servers, and files.

  • Authentication   A user authentication procedure can be written in Java or .NET so that MobiLink authentication integrates with your corporate security policies.

  • Stored procedures   If your RDBMS lacks the ability to use user-defined stored procedures, you can create a method in Java or .NET.

  • External calls   If your program calls for contacting an external server midway through a synchronization event, you can use Java or .NET synchronization logic to perform actions triggered by synchronization events. Java and .NET synchronization logic can be shared across multiple connections.

  • Variables   If your database lacks the ability to handle variables, you can create a variable in Java or .NET that persists throughout your connection or synchronization. (Alternatively, with SQL scripts you can use user-defined named parameters, which work with all consolidated database types. See User-defined named parameters.)

MobiLink server APIs

Java and .NET synchronization logic are available via the MobiLink server APIs. The MobiLink server APIs are sets of classes and interfaces for MobiLink synchronization.

The MobiLink server API for Java offers you:

  • Access to the existing ODBC connection to the consolidated database as a JDBC connection.
  • Access to alternate data sources using interfaces such as JDBC, web services, and JNI.
  • The ability to create new JDBC connections to the consolidated database to make database changes outside the current synchronization connection. For example, you can use this for error logging or auditing, even if the synchronization connection does a rollback.
  • For synchronizing with the consolidated database, the ability to write and debug Java code before it is executed by the MobiLink server. SQL development environments for many database management systems are relatively primitive compared to those available for Java applications.
  • Both SQL row handling and direct row handling.
  • The full richness of the Java language and its large body of existing code and libraries.

See MobiLink server API for Java Reference.

The MobiLink server API for .NET offers you:

  • Access to the existing ODBC connection to the consolidated database using iAnywhere classes that call ODBC from .NET.
  • Access to alternate data sources using interfaces such as ADO.NET, web services, and OLE DB.
  • For synchronizing with the consolidated database, the ability to write and debug .NET code before it is executed by the MobiLink server. SQL development environments for many database management systems are relatively primitive compared to those available for .NET applications.
  • Both SQL row handling and direct row handling.
  • Code that runs inside the .NET Common Language Runtime (CLR) and allows access to all .NET libraries, including both SQL row handling and direct row handling.

See MobiLink server API for .NET reference.

See also
Copyright © 2008, iAnywhere Solutions, Inc. - SQL Anywhere 11.0.0