The mechanism is the following: data sources manage listeners that listen for Rogue Wave® Server notification events. Data sources also provide an API to create, delete, and update Rogue Wave Server objects. To synchronize a given data source with the data model, an adapter listens for all incoming events, both from the data source and from the data model, and updates each other accordingly.

From the client side, the proper way to make updates is to use the data-source API to notify Rogue Wave Server, which in turn will update the object model.

The role of adapters and strategies is to enable interaction between representation objects and data model objects. However, representation objects do not store any data, they are empty proxy objects that only pass updates to the data sources. Data are meant to be stored in the data model. Sometimes, for convenience, some data may be stored in the adapter or in a strategy to enable conversion of representation data to a model or graphic data. For example, a lock-status data may be mapped to a specific background color for JTable rows.

You can extend the synchronization mechanism by subclassing adapters or creating new strategies for existing adapters. Those two ways are nearly equivalent, but strategies are more flexible and reusable. The main advantage in favor of strategies is that you can enable or disable them at runtime according to your requirements. In the following examples, we are going to show both ways of extending the synchronization mechanism.

Strategies are enhanced listeners of their adapter. Generally, a strategy is dedicated to manage specific properties, such as foreground and background colors of table rows. In this example, you would add this strategy to your table adapter only if you need to manage the color of table rows in your .ils file.