Depending on the application objects you want the Data Management Service to manage, you define one or more destinations in the data-management-config.xml file. Each destination maps directly to an application object that you want to manage. You define an assembler class for each destination.

Your assembler class only has to support the methods that correspond to the operations that the clients use. Your assembler usually implements at least one fill method. Fill methods implement queries, each of which returns a collection of objects to the client code. If your client must update objects, your assembler must include a sync method or individual create, update, and delete methods.

Depending on your server architecture, you directly transfer your domain model objects to the client or implement a distinct layer of data transfer objects (DAOs) that replicate only the model state you want to expose to your client tier.

The Data Management Service supports two approaches to writing custom assembler classes: the Assembler interface approach and the fill-method approach. The Assembler interface approach is a more traditional way to build Java components. You extend the flex.data.assemblers.AbstractAssembler class, which implements the flex.data.assemblers.Assembler interface. You override methods such as the getItem(), fill(), createItem(), and updateItem() methods. The AbstractAssembler class provides default implementations of all of the Assembler interface methods. The AbstractAssembler class and Assembler interface are documented in the LiveCycle Data Services ES Javadoc API documentation. For more information, see The Assembler interface approach.

The fill-method approach is designed for simple applications. You declare individual methods by using XML elements named fill-method, sync-method, and get-method in a destination definition in a configuration file. You map these XML elements to methods of any name on your assembler class. For more information, see The fill-method approach.

Add the methods required for the feature set required for your clients. For example, if your client application is read-only, you only have to provide a get method or a fill method as needed by your clients. A get method is required on an assembler if a client uses the DataService.getItem() method. A get method is also required if you set the value of the cache-items property to false and have lazy associations that point to an item or you are using paging. A fill method is required if a client uses the DataService.fill() method.

Later, if you want the assembler to support updates, you add a sync-method definition. In this approach, the assembler class does not have to implement any special Flex interfaces.

You can also combine the Assembler interface approach and the fill-method approach in the same assembler class. If you use an XML declaration for a method, the Data Management Service calls that method instead of the equivalent implementation of an Assembler interface method. Combining the Assembler interface approach with fill-method and count-method XML declarations in a destination definition can be a useful way to expose queries to your clients; it prevents the assembler's actual fill() method from acting on different types of fill requests. If a matching fill-method element is found in the destination, the Data Management Service calls that method. Otherwise, the Data Management Service calls the assembler's implementation of the fill() method defined in the Assembler interface.

Configuring a destination that uses a custom assembler

The following table describes the destination properties for using the Java adapter with a custom assembler. Unless otherwise indicated, these elements are subelements of the properties element.