LiveCycle Data Services ES applications consist of two parts: client-side code and server-side code. Before you start developing your application, configure your development environment, including the directory structure for your client-side source code and for your server-side source code.

Installation directory structure

The LiveCycle Data Services ES installer creates a directory structure on your computer that contains all of the resources necessary to build your application. As part of the installation, the installer creates three web applications that you can use as the basis of your development environment.

The following example shows the directory structure of the web applications installed with LiveCycle Data Services ES:

The installer gives you the option of installing the integrated Tomcat application server to host these web applications. Alternatively, you can install LiveCycle Data Services ES without installing Tomcat. Instead, you deploy the LiveCycle Data Services ES web application on your J2EE application server or servlet container.

The following table describes the directory structure of each web application:

Accessing a web application

To access a web application and the services provided by LiveCycle Data Services ES, you need the URL and port number associated with the web application. The following table describes how to access each web application assuming that you install LiveCycle Data Services ES with the integrated Tomcat application server.

If you install LiveCycle Data Services ES with the integrated Tomcat application server, you can also access the ROOT web application by using the following URL: http://localhost:8400/.

Creating a web application

To get started writing LiveCycle Data Services ES applications, you can edit the samples in the lcds-samples application, add your application code to the lcds-samples application, or add your application code to the empty lcds application. However, Adobe recommends leaving the lcds application alone, and instead copying its contents to a new web application. That leaves the lcds web application empty so that you can use it as the template for creating web applications.

Defining the directory structure for client-side code

You develop LiveCycle Data Services ES client-side applications in Flex, and compile them in the same way that you compile applications that use the Flex Software Development Kit (SDK). That means you can use the compiler built in to Flex Builder, or the command line compiler, mxmlc, supplied with the Flex SDK.

When you develop applications, you have two choices for how you arrange the directory structure of your application:

• Define a directory structure on your computer outside any LiveCycle Data Services ES web application. Compile the application into a SWF file, and then deploy it, along with any run-time assets, to a LiveCycle Data Services ES web application.
• Define a directory structure in a LiveCycle Data Services ES web application. In this scenario, all of your source code and assets are stored in the web application. When you deploy the application, make sure to deploy only the application SWF file and run-time assets. Otherwise, you run the risk of deploying your source code on a production server.

You define each application in its own directory structure, with the local assets for the application under the root directory. For assets shared across applications, such as image files, you can define a directory that is accessible by all applications.

The following example shows two applications, appRoot1 and appRoot2. Each application has a subdirectory for local MXML and ActionScript components, and can also reference a library of shared components:

Defining the directory structure for server-side code

You develop the server-side part of a LiveCycle Data Services ES application in Java. For example, the client-side RemoteObject component lets you access the methods of server-side Java objects to return data to the client.

You also write Java classes to extend the functionality of the LiveCycle Data Services ES server. For example, a Data Management Service destination references one or more message channels that transport messages, and contains network- and server-related properties. The destination can also reference a data adapter, server-side code that lets the destination work with data through a particular type of interface such as a Java object. An assembler class is a Java class that interacts indirectly or directly with a data resource. For more information on assemblers, see Standard assemblers.

When you develop server-side code, you have several choices for how you arrange the directory structure of your application:

• Define a directory structure that corresponds to the package hierarchy of your Java source code outside any LiveCycle Data Services ES web application. Compile the Java code, and then deploy the corresponding class files and JAR files, along with any run-time assets, to a LiveCycle Data Services ES web application.
• Define a directory structure in a LiveCycle Data Services ES web application. In this scenario, all of your source code and assets are stored in the web application. When you deploy the application, make sure to deploy only the class and JAR files. Otherwise, you risk deploying source code on a production server.

The WEB-INF/classes and WEB-INF/lib directories are automatically included in the classpath of the web application. When you deploy your server-side code, place the compiled Java class files in the WEB-INF/classes directory. Place JAR files in the WEB-INF/lib directory.