Funabol Connector Development Roadmap

  • 1,958 views
Uploaded on

 

More in: Education , Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
1,958
On Slideshare
0
From Embeds
0
Number of Embeds
2

Actions

Shares
Downloads
61
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. Connector Development Roadmap Gilberto Migliavacca
  • 2. Index
    • DS Server
    • Extending the DS Server
    • SyncSource
    • Configuration Panels
    • Officer
    • Hands-on
    • Listener Service
    • Conclusion
  • 3. Index
    • DS Server
    • Extending the DS Server
    • SyncSource
    • Configuration Panels
    • Officer
    • Hands-on
    • Listener Service
    • Conclusion
  • 4. DS Server
    • The DS-Server is SyncML server that receives SyncML requests from many remote devices, updates their remote data with local modifications and updates their local data with remote modifications
    • The DS-Server is data format independent; it doesn't care about the nature of the item. it considers just the Id of the items.
  • 5. DS Server
    • It keeps a mapping table between the client’s Local Unique ids (LUID) and the server’s Global Unique Ids (GUID)
  • 6. DS Server
    • A DS Server common purpose is to keep in sync a syncML Device (e.g. Mobile Phone) with a Back-End System (e.g. Enterprise Information System)
  • 7. Index
    • DS Server
    • Extending the DS Server
    • SyncSource
    • Configuration Panels
    • Officer
    • Hands-on
    • Listener Service
    • Conclusion
  • 8. Extending DS Server
    • The DS Server can be extended in many areas in order to integrate Funambol into existing systems.
    • The DS Server extension is called “Module”
    • Extensions are distributed and deployed as Funambol Modules
  • 9. Extending DS Server
    • Module : it's a container for anything related to a server extensions which are used by the DS Server engine to communicate and integrate with external systems.
    • Connector : when the main purpose is to connect to an external data source, the module is called connector.
  • 10. Extending DS Server
    • SyncSource : the connector must provide a SyncSource component. The SyncSource knows and manages a specific data format .
    • - FileSystemSyncSource is used by the ds server engine to synchronize data stored in the file system.
    • - ContactSyncSource is used to synchronize Contact object (e.g. Vcard)
    • - HomerSyncSource is used to synchronize
    • Homer Object 1.0
  • 11. Extending DS Server
    • A Module should contains:
    • - Officer: link to an external authentication/authorization service
    • - SyncSource: link to an external data source
    • - WS Admin Panel: link for an external management tool
  • 12. Extending DS Server
    • Moreover a Module
    • should contains:
    • - XML configuration files
    • - Installation instructions
    • - SQL scripts
  • 13. Extending DS Server
    • XML
    • configuration
    • files
    • (SyncSource)
  • 14. Extending DS Server
    • SQL scripts
    • - fnbl_module : for module information
    • - fnbl_connector : for connector information
    • - fnbl_module_connector : for module-connector association
    • - fnbl_sync_source_type : for SyncSource type information
    • - fnbl_connector_source_type : for connector-SyncSource type associations
  • 15. Index
    • DS Server
    • Extending the DS Server
    • SyncSource
    • Configuration Panels
    • Officer
    • Hands-on
    • Listener Service
    • Conclusion
  • 16. SyncSource
    • The SyncSource identifies the remote database that will be synchronized with the client database;
    • Any type of data (files, calendar events, Homer Object , etc.) can be synchronized, but there must be a proper SyncSource for each type, capable of extracting and storing the data for a real data store.
  • 17. SyncSource
    • SyncSource Interface Methods:
    • - Begin Sync / End Sync : used to start and to end a sync.
    • - Get All Sync Item Keys : get all the keys for the items in the server.
    • - Get Deleted Sync Item Keys : get all the keys of the deleted items since a specified time.
    • - Get Updated Sync Item Keys : get all the keys of the updated items since a specified time.
    • - Get New Sync Item Keys : get all the keys of the new items since a specified time.
  • 18. SyncSource
    • - Get Sync Item From Id : get the item associated with a specific key.
    • - Get Sync Item Keys From Twin : search equivalent items for a specified item.
    • - Remove Sync Item : remove the item with a specific key.
    • - Add Sync Item : insert a specified item in the server and return the item key.
    • - Update Sync Item : update a specified item in the server for a specific key.
    • - setOperationStatus : the system can perform some actions on the exchanged items based on the client answer. The operations are executed just before the endSync method.
  • 19. SyncSource
    • Funambol provides two subtypes of
    • the SyncSource interface
    • - Mergeable : used when the data synchronized supports the merge operation. The merge is performed when a conflict is detected in order to avoid a loss of whatever information. For instance, synchronizing the contacts, we can have the same contact updated on the server (we suppose a new address has been added) and on the client (we suppose a new phone has been added); in this case, we can merge the server contact and the client contact keeping the new address and the new phone
    • - Filterable: this interface should be used when the SyncSource supports the Filter (SyncML 1.2)
  • 20. SyncSource
    • Mergeable
    • - mergeSyncItems : Called by the engine to merge the server item with a specific key with the content obtained from the client. This method must return true if the content has been changed. Moreover the item, resulting from the merge, will be sent back to the client.
  • 21. SyncSource
    • Filterable
    • - isSyncItemInFilterClause : detects if the given item matches the filter clause. Called to know if an item satisfies the filter
    • - isSyncItemInFilterClause : detects if the item linked to the key matches the filter clause. Called to know if the item specified with the given key satisfies the filter
    • - getSyncItemStateFromId : Get the “status” of the given item. This method is required because the server is not able to know the status of an item not inside the filter criteria
  • 22. Index
    • DS Server
    • Extending the DS Server
    • SyncSource
    • Configuration Panels
    • Officer
    • Hands-on
    • Listener Service
    • Conclusion
  • 23. Configuration Panel
    • A Connector and the included SyncSource can be managed by the Administration Tool provided by Funambol.
    • The Administration tool uses the WS Admin Interface so that the Module should contain a subset of classes that implement the WS Interface.
    • These classes compose the Configuration Panels.
  • 24. Configuration Panel
    • The Connector Config Panel
    • - extends the ConnectorManagementPanel class
    • - keeps common settings for all module components/syncsources
    • The SyncSource Config Panel
    • - extends the SourceManagementPanel class
    • - keeps specific settings for a given object ( files, contacts, calendar events and so on)
  • 25. Configuration Panel
    • Configuration Panels Layout
  • 26. Configuration Panel
    • .. what's the Homer Object 3.0
    • Homer 3.0
    • Homer 3.0 – drunk
  • 27. Configuration Panel
    • The Configuration Panels use as a storage system the XML files on the File System.
    • Path: Foundation Connector
    • /opt/Funambol/config/foundation/.../*.xml
  • 28. Index
    • DS Server
    • Extending the DS Server
    • SyncSource
    • Configuration Panels
    • Officer
    • Hands-on
    • Listener Service
    • Conclusion
  • 29. Officer
    • Component responsible for authenticating and authorizing users to access the server or a particular resource
    • A user is represented by its credentials (e.g. login/password pair )
    • A resource can be a SyncML database, a SyncML item or whatever else must be protected by the authorized access.
    • An officer is a java class that implements the com.funambol.framework.security.Officer interface
  • 30. Officer
    • Officer Interface Methods:
    • - boolean authenticate(Credential credential) : Is the user valid? The authentication is valid for an entire SyncML session.
    • - boolean authorize(java.lang.String resource, Credential credential) : Is the user authorized to access the given resource?
    • - void unAuthenticate(Credential credential) : Used to invalidate the given credential for the current session.
    • - getClientAuth() : returns the authentication type that the client must send
    • - getServerAuth() : returns the authentication type that the server must send
  • 31. Officer
    • The Officer has a configuration file
    • path:
    • opt/Funambol/config/com/funambol/server/security/*.xml
  • 32. Index
    • DS Server
    • Extending the DS Server
    • SyncSource
    • Configuration Panels
    • Officer
    • Hands-on
    • Listener Service
    • Conclusion
  • 33. Hands-on
    • Has the back-end database the fields: “status” and “last_update” for the interested entity?
    • e.g. Contact table fields:
  • 34. Hands-on
    • If the back-end system doesn't provide this feature the Connector must have a local cache in order to idetify:
    • - new items (“ getNew ”)
    • - updated items (“ getUpdated ”)
    • - deleted items (“ getDeleted ”)
    • between two SyncML sessions
  • 35. Hands-on
    • is the communication between the DS Server and the Back-End system fast?
    • e.g. HTTP communication
  • 36. Hands-on
    • If the communication is slow we can optimize the HTTP request for the “ getTwin ” Method.
    • The Connector can perform a single “getAll” with just the fields required by the search criteria.
    • Then the Connector can save this list of information in the session and execute a local search for all the “ getTwin ” calls.
  • 37. Hands-on
    • is the appointment and task in the same client database?
    • e.g. Nokia
    • Phone
  • 38. Hands-on
    • The Calendar SyncSource must be able to manage a nested object like the ical/vcal.
    • Every method should be able to understand if the item is an Event or a Task (Todo)
    • Usually we use the following GUID format
    • - event: E-121231
    • - task : T-43242
    • in this way the “ getItem ” method can understand if it's handling an Event or a Task.
  • 39. Hands-on
    • A SyncSource (e.g. PIM SyncSource) can be developed using a three layer architecture
    The SyncSource layer implements all methods prescribed by the SyncSource interface. It manages the SyncItem/SyncItemKey objects and converts them into “Foundation PIM objects” The Manager layer wraps/unwraps the “Foundation PIM objects” with additional backend-oriented data. The DAO layer manages the operations on the BackEnd
  • 40. Hands-on
    • The schema
    • of the
    • OX Connector
  • 41. Index
    • DS Server
    • Extending the DS Server
    • SyncSource
    • Configuration Panels
    • Officer
    • Hands-on
    • Listener Service
    • Conclusion
  • 42. Listener Service
    • The “listener” service is a java process and is not deployed in the DS Server container (i.e. Tomcat)
  • 43. Listener Service
    • The “listener” enables the PUSH feature of the Funambol platform.
    • The “listener” component is not a part of the Module, but can complete the feature of a Connector included in the Module
    • - PIM Listener: the PIM sync process do not dependes on this component
    • - INBOX Listener: the EMAIL sync process depends on this component
  • 44. Listener Service
    • Listening systems:
    • - polling system: the listener polls the back-end system with a given period in order to check the changes of the status of the sync'ed entity.
    • - notifiable system: the listener waiting for a massage from the back-end system when the status of the sync'ed entity changes.
  • 45. Listener Service
    • .. so the “listener” monitors when the status changes.
    notification
  • 46. Listener Service
    • The “listener” uses the “Push framework” developed by Funambol.
    • This is out of scope of this presentation, but remember to take a look at that component if you want to implement a good “listener”
  • 47. Index
    • DS Server
    • Extending the DS Server
    • SyncSource
    • Configuration Panels
    • Officer
    • Hands-on
    • Listener Service
    • Conclusion
  • 48. Conclusions
    • Connector
    • - SyncSource (Files, PIM, Email, ... )
    • - Configuration Panel (Connector and SyncSource)
    • - Officer
    • Listener
    • - polling
    • - notifiable
  • 49. Conclusions
    • .. and now Happy Hour
    • After sniper session (sigh)
  • 50. The End