Create Data Services applications for the Experience Server using APIs

You can create Data Services applications for the Experience Server by using Data Services APIs. When creating a Data Services application, you typically create a client application and application logic that runs on the server. Java source files that perform business logic, such as querying data from an enterprise database, are placed into an Experience Services package. An Experience Service package is a ZIP file that you deploy to the Experience Server. For more information about packages, see Use of OSGi.

Setting Data Services Destinations

When creating a Data Services application for the Experience Server, you define the server-side destination in Data Services XML configuration files. A destination lets a client application invoke operations exposed by the class that is located in the package. An XML configuration file must be placed in the Experience Server repository for a client application to invoke operations exposed by the package.

The following XML configuration files are supported:

You can add XML configuration files to the repository by using one of the following ways:

• You can use CRXDE Lite to manually add an XML configuration file to the repository.

• You can package the XML configuration file in an Experience Services package that you deploy to the repository. The XML configuration file is added to the repository when you deploy the package.

The following topics demonstrate how to add an XML configuration files to the repository by using CRXDE Lite:

• Create a Data Services application for the Experience Server that returns data

• Create a Data Services application for the Experience Server that displays messages

The following topic demonstrates how to place the XML configuration file in the package: Create a Data Services application for the Experience Server that retrieves data from the sample database.

Message Broker

The Experience Server contains a Message Broker that enables packages to expose themselves as destinations. There is only one Message Broker within the server. When you modify and save a Data Services configuration file, the message broker is automatically restarted. For example, if you create a destination in a Data Services configuration file and save the file, Message broker is restarted. You can then use the destination from a client application. For information about modifying Data Services configuration files, see Defining the server destination for the echo service.

Options for using OSGi for Flex Remoting

When creating a package as part of creating a Data Services application, you have the following options to expose server operations to client applications, such as a Flex client application:

1. Use a standard Java class and reference it when creating a destination using a Data Services XML configuration file. (Most of the topics in this section show this way.)

2. Setup the destination by using the Data Services XML configuration file. Set the factory attribute to OSGi. Set the source element to reference the interface class, as shown in the following example.

    <destination id="lcds.test.echoservice "> 
           <properties> 
               <factory>osgi</factory> 
               <source>com.adobe.lcds.test.EchoServiceInterface</source> 
           </properties> 
   </destination>

3. Use SCR annotations to build a package that contains an OSGi service. You can only define the destination ID value, nothing else. If you want to provide more configuration information, use one of the other two ways that use a Data Services XML configuration file. When using this way, you do not define a destination in a Data Services XML configuration file. The following example shows SCR annotations defined at the class level.

   @Service(value=EchoServiceInterface.class) 
   @Properties({ 
           @Property(name = "connectors.remoting.id", value = "lcds.test.echoservice") 
   }) 
   public class EchoService implements EchoServiceInterface {