----
h1. Creating a caGrid Data Service Backed by caCORE SDK 4.0

caGrid [Data Service|dataservices:Home] creation is accomplished by the use of an [extension|introduce12:Technical Guide] to the [Introduce toolkit|introduce:Home]. This extension can streamline the process of creating a data service backed by the [caCORE SDK|dataservices:caCORE SDK Support] using a wizard like interface which prompts for values as required, or simply make use of a [custom query processing|dataservices13:How-to Implement CQL Query Processors] back end.

{cagridroundpanel}
{pre:class=cagridheaderfont}Table of Contents{pre}
{toc:outline=false|exclude=Creating a caGrid Data Service backed by caCORE SDK 4.0|style=bullets}
{cagridroundpanel}

h2. Prerequisites

This tutorial assumes you have your system configured for both caGrid 1.2 as well as caCORE SDK 4.0.

* A full caGrid 1.2 installation
** This installation is rooted at %CAGRID_LOCATION%, an environment variable set to reference the base directory
* Access to a caCORE SDK 4.0 installation on the local file system
** The SDK must be configured to use the example model supplied with the download of the SDK
** The SDK system has been built and installed
* Network access to the installed caCORE SDK 4.0 system

* Download caCORE SDK ([http://gforge.nci.nih.gov/frs/?group_id=148])
* Create UML model and Data model ([caCORE SDK 4.0 Developer's Guide|http://gforge.nci.nih.gov/docman/view.php/148/8650/caCORE%20SDK%204.0%20Developer's%20Guide_101007.pdf])
* Perform mapping between Object and Data model using UML tag values or preferably you can use caAdapter ([caAdapter|http://ncicb.nci.nih.gov/NCICB/infrastructure/cacore_overview/caadapter])
* Generate a system using SDK by supplying your UML model as input

_Note:_ The SDK has a sample model which you can use to generate a system and subsequently create a grid service with the same model.

A high-level description of the features and usage of the SDK can be found in the [caCORE SDK 4.0 Developer's Guide|http://gforge.nci.nih.gov/docman/view.php/148/8650/caCORE%20SDK%204.0%20Developer's%20Guide_101007.pdf]

If you do not wish to build the caCORE SDK system yourself, a minimal set artifacts required to complete the tutorial is provided in the [caGrid tutorial materials download page.|https://project.bmi.ohio-state.edu/gf/download/frsrelease/117/510/DataServices_SDK_40_Tutorial.zip]

Once downloaded, the zip file contains the following items:

* README.txt
** A document describing the contents of the zip
* caCore4MinimalOutput.zip:
** Contains the 'output' folder resulting from building the caCORE SDK 4.0 using the supplied example uml model, pared down to remove files not required by the data service wizard or runtime
** This may be unpacked and used in the tutorial's "Configuring the Client" step.
* sdkExampleDomainModel.xml:
** The domain model document which represents the caCORE SDK's example object model
* Sdk4Example.zip:
** The completed tutorial service in zip format
** See the enclosed README.FIRST.txt in the unpacked zip for usage instructions

h2. Launch the Introduce Grid Service Authoring Toolkit

In a system terminal execute the following commands to launch Introduce

{terminal}
%> cd %CAGRID_LOCATION%
%> ant introduce
{terminal}

h1. Create the Service Skeleton
----

# Select *{_}Create caGrid Service Skeleton{_}* from the toolbar at the top of the Introduce portal, or select Tools \-> Create caBIG Service from the menu. The Create caBIG Grid Service screen will appear.
# Choose a directory in which to place the generated service. This tutorial uses *_"C:\caGrid\generatedServices\Sdk4Example"_*.
# Type in the Service Name. This tutorial will use *_"Sdk4Example"_*.
# Choose a Package Name. This tutorial will use *_"org.cagrid.sdk4.example"_*.
# Choose a Namespace. This tutorial will use *_"http://example.sdk4.cagrid.org/CaGridTutorialService"_*.
#* NOTE: The service creation dialog will attempt to guess this for you from your package and service names.
# Select the *{_}Data Service{_}* radio button from the Customize Service section.{attached-image:tablealign=center|attachmentname=DataService_1.2_SDK_4_Creation.png}
# Click the *{_}Create{_}* button located at the bottom of the creation screen.

h2. Select the Service Style

The caGrid data services extension provides a pluggable framework for creating highly custom data services known as [data service styles|dataservices:Documentation]. Styles may be provided by a third party, or installed with caGrid. Styles are provided to create data services backed by various caCORE SDK.
# When the *{_}Data Service Configuration{_}* window appears, use the drop down menu to select the *_"caCORE SDK v 4"_* option.
# Leave the check boxes for WS-Enumeration and Bulk Data Transport unchecked for this tutorial
#* These options enable specialized results retrieval for the data service.{attached-image:tablealign=center|attachmentname=DataService_1.2_SDK_4_Style_Selection.png}
# Click the *{_}OK{_}* button to continue with the selected service style.

h2. The Data Service caCORE SDK 4 Wizard

The caCORE SDK v 4 data service style provides a wizard interface which is run prior to generation of the data service's source code. This wizard provided facilities to select the client interface to the caCORE SDK and configure it, as well as selection of a domain model and mapping that domain to XML schemas for use on the grid.{attached-image:tablealign=center|attachmentname=DataService_1.2_SDK_4_Wizard_Step_1.png}
This panel is strictly informational. The wizard displays the current step in the lower left hand corner of the window, and provides simple 'Previous' and 'Next' buttons to navigate the steps. These buttons will become enabled and disabled as the content of each page is validated. If any fields on the current page are in an invalid state, the 'Next' button will be disabled, and the field will show a red highlight. Mouse-over tooltips are used to indicate the problem. When all steps are complete, the 'Next' button becomes 'Finish', and will complete the wizard and proceed to code generation. Click the *{_}Next: Configuration{_}* button to continue the wizard.

h3. Configuring the Client

The next step of the wizard.{attached-image:tablealign=center|attachmentname=DataService_1.2_SDK_4_Wizard_Step_2_Blank.png}
This panel allows the service developer to select various outputs from the caCORE SDK which are required by the caGrid data service to utilize it as a data resource. There are two modes of operation for this panel: 'simple' and 'advanced', selectable by way of radio buttons near the top-left of the panel. In 'simple' mode, the developer is prompted to select the output directory in a caCORE SDK installation, and the extension will attempt to locate the other components it requires in its subdirectories.{attached-image:tablealign=center|attachmentname=DataService_1.2_SDK_4_Select_Output_Dir.png}

h3. Selecting the Output Directory

Alternatively, the service developer may select the required components manually by first selecting the 'Advanced' option, then using the provided 'Browse' buttons to populate each field. Once these file location fields have been populated, the service developer may then select to use the 'local' or 'remote' application service APIs. The remote API connects to a caCORE SDK application via HTTP transport, and requires a URL. The local API bypasses HTTP transport all together, and communicates directly with the Hibernate layer of the caCORE SDK. This option should improve performance by removing a level of network overhead, but will only function properly in cases where the grid data service will be deployed on the same machine that the caCORE SDK system is deployed to.

# For this tutorial, use the *{_}Simple{_}* option for configuration, and select the output directory of your caCORE SDK 4.0 installation. This example uses *_"c:/caCore4Release/output"_*.
## If you are wish to use the minimal caCore SDK output available in the prerequisites, the file _DataServices_SDK_40_Tutorial.zip_ must first be extraced, then extract the resulting archive _caCore4MinimalOutput.zip._
## In *Simple* mode, after choosing the directory, all of the fields in the dialog should be populated with the desired information except the *hostname* and the *port number*.
# Select the *{_}Remote API{_}* radio button.
#* This enables fields specific to this API
# Set the host name of the machine where the remote application service is running by filling in the text field next to *{_}Host Name{_}*. This text field requires the user to enter a URL (for example [http://www.example.com]).
# Set the port on which the remote application service is configured to accept connections by filling in an integer in the text field labeled *{_}Port{_}*. Typically, this is port *{_}8080{_}*.{attached-image:tablealign=center|attachmentname=DataService_1.2_SDK_4_Wizard_Step_2_Full.png}
# Click the *{_}Next{_}* button on the wizard to continue.

h3. Application Service Security

The caCORES SDK Application Service can be configured to require a user name and password for access. If the service is so configured, this panel allows the service developer to specify which user name and password should be used. Two options are available. One option allows a static, single user name and password to be used for all connections to the application service. The other option attempts to use the grid identity of the user making a query to the data service as the user name.{attached-image:tablealign=center|attachmentname=DataService_1.2_SDK_4_Wizard_Step_3.png}
For this tutorial, simply leave all fields blank and unchecked on this page, and click *{_}Next{_}*.

h3. Selecting a Domain Model

All caGrid data services are required to expose a domain model in their service metadata. This domain model describes the classes available in the data service, as well as their attributes, and relationships to one another. Using this model, a client can formulate queries, and discover data services which contain information they may be interested in. Additionally, the data service itself can use this information to validate queries for their correctness and map domain objects to their XML document representations. Models may be supplied from the caDSR, or from the local file system. For this tutorial, a domain model will be supplied which represents the caCORE SDK version 4 example model.

1. Select the *{_}Domain Model From File{_}* radio button.
* This will disable components not relevant to this function, and enable the file selection fields.

2. Click the *{_}Browse{_}* button at the right hand side of the field labeled *{_}Domain Model File{_}*.

3. Navigate to the location of *{_}sdkExampleDomainModel.xml{_}*, and click 'Open' in the file browser.
* This domain model file is available [here|http://gforge.nci.nih.gov/plugins/scmcvs/cvsweb.php/%7Echeckout%7E/cagrid-1-0/caGrid/projects/sdkQuery4/test/resources/sdkExampleDomainModel.xml?rev=1.2;content-type=text%2Fplain;cvsroot=cagrid-1-0]
* Once selected, the packages contained in domain model will be displayed in a list on the panel.

{attached-image:tablealign=center|attachmentname=DataService_1.2_SDK_4_Wizard_Step_4_Full.png}

{info}
Note: to use another domain model file (for example, if you're creating a data service from another caCORE SDK 4 project), please use the following steps:

1. cd to $CAGRID_LOCATION/projects/dataExtensions
2. ant xmiToDomainModel
3. Point to the XMI file exported from EA per the caCORE SDK 4.0 programmer's guide instructions
4. Select "caCORE SDK 4.0 XMI from EA" as the XMI type
5. Type in a project short name
6. Type in a project version
7. Click OK
8. Choose where to save your domain model file and type in a name.
{info}

4. Click the *{_}Next{_}* button to continue to the last step in the wizard.

h3. Mapping Domain Packages to XML Schema

Every class exposed by the domain model must be supplied with a corresponding XML schema representation so it may be utilized in the grid. The mapping panel of this wizard streamlines this process by simultaneously generating the mapping from model to schema and configuring serialization of the XML data types to correspond to the domain model's Java beans.{attached-image:tablealign=center|attachmentname=DataService_1.2_SDK_4_Wizard_Step_5_Unresolved.png}
Packages from the domain model are listed, along with a suggested XML schema namespace, a mapping status, and a button to manually resolve the mapping for each package. This panel contains two buttons which serve as convenience methods for mapping a large batch of packages to their schemas. The 'Map From GME' button attempts to locate the suggested namespaces in the Global Model Exchange service and pull the corresponding schemas. The 'Map From Config' button makes use of the XML schemas provided by the caCORE SDK's output to map to each package of the domain model.

1. Click the *{_}Map From Config{_}* button, and this mapping will be performed automatically.
* If this operation succeeds, the mapping status of each package will change from 'Unknown' to 'Found', and the 'Done' button will be enabled.

{attached-image:tablealign=center|attachmentname=DataService_1.2_SDK_4_Wizard_Step_5_Resolved.png}

2. Click the *{_}Done{_}* button to complete the wizard.

h3. Creation Process Complete

Once the wizard has been completed, the Introduce toolkit and data services extension will generate the code, wsdl, and other files required to complete the grid service generation. This process can take a few minutes depending on the selection of your domain model and speed of your system. Once this code generation process is complete, Introduce will display the service modification user interface, including the specialized tab for managing data service components.

h2. Deploying the Data Service

Once a caGrid data service has been created, it must be deployed to a service container so it can be invoked.

h3. Cleaning Up the Container

This tutorial will deploy the generated grid data service to the Tomcat container. If other caGrid services (especially other data services) have been deployed to the container, class path conflicts can arise in the running service. If this is the case, before deploying the service, make sure the Tomcat container is totally clean of all other caGrid services. You can do this by removing the _wsrf_ directory under the _webapps_ directory inside the Tomcat base directory:

*{_}Linux / Unix{_}*
{terminal}
%> cd $CATALINA_HOME
%> rm \-rf webapps/wsrf
{terminal}

*{_}Windows{_}*
{terminal}
%> cd %CATALINA_HOME%
%> rmdir /S webapps\wsrf
{terminal}

h3. Deploying Globus

Once the wsrf folder has been removed, deploy Globus to Tomcat:

*{_}Linux / Unix{_}*
{terminal}
%> cd $GLOBUS_LOCATION %> ant \-f share/globus_wsrf_common/tomcat/tomcat.xml deployTomcat \-Dtomcat.dir="$CATALINA_HOME"
{terminal}

*{_}Windows{_}*
{terminal}
cd %GLOBUS_LOCATION% ant \-f share\globus_wsrf_common\tomcat\tomcat.xml deployTomcat \-Dtomcat.dir="%CATALINA_HOME%"
{terminal}

h3. Deploying the Service

Now the generated grid service may be deployed to the Tomcat container. The tutorial uses _C:\caGrid\generatedServices\Sdk4Example_; if you selected a different directory, substitute it appropriately. The following command will recompile the service and deploy it to the tomcat container residing at $CATALINA_HOME:

{terminal}
cd C:\caGrid\generatedServices\Sdk4Example ant all deployTomcat
{terminal}

h3. Starting Tomcat

Start the Tomcat container so that the service can be invoked using grid calls.

*{_}Linux / Unix{_}*
{terminal}
%> cd $CATALINA_HOME %> bin/startup.sh
{terminal}

*{_}Windows{_}*
{terminal}
cd %CATALINA_HOME% bin\startup.bat
{terminal}

h2. Invoking the Grid Data Service

Once the tutorial caGrid data service has been created and deployed to a service container, it may be invoked by a grid service client. This tutorial covers importing the project into Eclipse, importing [CQL|dataservices:CQL] queries from XML, and making use of the generic data service client tooling to query the service and print results.

h3. Importing the Service into Eclipse

All Introduce generated caGrid services contain both a .project and a .classpath file, which Eclipse uses to determine properties for a Java project (source folders, code builders, libraries, etc). While it is not required to use Eclipse for this tutorial, doing so makes it easier to make changes to the source code, and simplifies testing the client.

{attached-image:tablealign=center|attachmentname=Eclipse_Import_Project_1.png}

To import the project into the Eclipse workspace, select '''Import''' from the '''File''' menu in Eclipse. Then select '''Existing Projects into Workspace''' under '''General'''. Click '''Next'''. Then, select the root directory of the tutorial service using the '''Browse''' button. Once the directory is selected, the name of the project (matching that of the service) will appear in the list. Click '''Finish''' to import the tutorial service as an Eclipse project.

h3. Creating a Test Class

To begin making use of the tutorial service, we'll need a place to put source code, as well as an implementation file to make use of the generic data service client and handle some query results. While the client class produced with the service itself can be used for basic testing, domain specific logic should never be placed in the client when used in a production level system. This is because the client may be regenerated, or have methods added and removed by the Introduce toolkit as changes are made to the service model.

h3. Create a New Source Package

To create a new package, expand the '''Sdk4Example''' project in Eclipse, followed by the folder named '''src'''. This directory houses the source code generated by Introduce which implements the grid service. Create a new package named _org.cagrid.sdk4.example.tutorial_ under the source directory. In Eclipse, this is as easy as right-clicking '''src''', and selecting '''New->Package.''' Fill in the name of the package, and click '''Finish.'''
{attached-image:tablealign=center|attachmentname=Data_Services_SDK_4_Tutorial_Add_Package.png} Alternatively, this new package may be created as a directory on the file system. From the command line, create the directory _src/org/cagrid/sdk4/example/tutorial_.

h3. Create a New Class

To create some code which can invoke the grid data service, begin by creating a new Java class. In Eclipse, right click the newly created package, and select '''New->Class'''. Name the class '''QueryRunner''', and check the box to create a main method, which will make the class executable. Click '''Finish''' to create this class and have Eclipse generate the shell of it.
{attached-image:tablealign=center|attachmentname=Data_Services_SDK_4_Tutorial_New_Class.png} Alternatively, the class can be created as a simple text file named QueryRunner.java in the src/org/cagrid/sdk4/example/tutorial directory. Once created, the class template should look something like this:

{code}
package org.cagrid.sdk4.example.tutorial;

public class QueryRunner {

public static void main(String[] args) {
// TODO Auto-generated method stub

}
}
{code}

h3. Create a Class Constructor

For the purposes of this tutorial, we'll create a very simple class constructor for the QueryRunner class. Copy and paste the following code into the new java file, immediately after the class declaration and opening bracket:

{code}
private String serviceUrl;
private String queryFilename;

public QueryRunner(String serviceUrl, String queryFilename) {
this.serviceUrl = serviceUrl;
this.queryFilename = queryFilename;
}
{code}

This constructor simply takes two string properties and stores them in instance variables. These values will be used later to create a client to the remote data service, and load a CQL query from the local file system.

h3. Adding a Query Method

Now a method must be added to the class which can handle invocation of the data service. In the new class file, add the following code after the constructor declaration:

{code}
private void performQuery() {
try {
// initialize the generic data service client
DataServiceClient client = new DataServiceClient(serviceUrl);
// deserialize the CQL query
CQLQuery query = (CQLQuery) Utils.deserializeDocument(queryFilename, CQLQuery.class);
// execute the query on the data service
System.out.println("Querying");
CQLQueryResults results = client.query(query);
// create a results iterator
System.out.println("Iterating");
Iterator iter = new CQLQueryResultsIterator(results, true);
// iterate and print XML
while (iter.hasNext()) {
String value = (String) iter.next();
System.out.println("-- RESULT --");
System.out.println(value);
}
System.out.println("Done");
} catch (Exception ex) {
ex.printStackTrace();
}
}
{code}

This code adds a method named '''performQuery''', which creates a generic data service client, loads a CQL query from the file system, invokes the query, and finally prints XML results to the console.

Additionally, some import statements must be added to the class. At the top of the class file, below the package declaration and before the class declaration, add the following:

{code}
import java.util.Iterator;

import gov.nih.nci.cagrid.common.Utils;
import gov.nih.nci.cagrid.cqlquery.CQLQuery;
import gov.nih.nci.cagrid.cqlresultset.CQLQueryResults;
import gov.nih.nci.cagrid.data.client.DataServiceClient;
import gov.nih.nci.cagrid.data.utilities.CQLQueryResultsIterator;
{code}

These statements make code from caGrid available in this class, including utilities, the data service client, and query and results handling code.

h3. Implement the Main Method

The last addition to the QueryRunner class is the implementation of the main method. We'll use this method to pass a service URL and query file name to the QueryRunner utility, and then to invoke the newly added performQuery() method. Copy the following code into the main method, replacing the text ''// TODO Auto-generated method stub'':

{code}
if (args.length != 2) {
System.err.println("USAGE: <serviceUrl> <queryFilename>");
System.exit(1);
}
QueryRunner runner = new QueryRunner(args[0], args[1]);
runner.performQuery();
{code}

Once all code has been added to the QueryRunner class, save the java file.

h2. An Example Query

To make use of the QueryRunner class, we'll need a CQL query which can be executed against the data service developed earlier. Create an xml file in the root of the tutorial service directory named '''exampleCqlQuery.xml.''' For example, the directory might look like "C:\caGrid\generatedServices\Sdk4Example". Copy and paste into it the following CQL query in XML form:

{code}
<ns1:CQLQuery xmlns:ns1="http://CQL.caBIG/1/gov.nih.nci.cagrid.CQLQuery">
<ns1:Target name="gov.nih.nci.cacoresdk.domain.other.levelassociation.Suit">
<ns1:Association name="gov.nih.nci.cacoresdk.domain.other.levelassociation.Card">
<ns1:Group logicRelation="AND">
<ns1:Association name="gov.nih.nci.cacoresdk.domain.other.levelassociation.Suit" roleName="suit">
<ns1:Attribute name="name" predicate="EQUAL_TO" value="Spade"/>
</ns1:Association>
<ns1:Attribute name="Name" predicate="EQUAL_TO" value="Ace"/>
</ns1:Group>
</ns1:Association>
</ns1:Target>
</ns1:CQLQuery>
{code}

This query will return Suit instances from the example service. These have the requirement that they be associated with a Card, which in turn has an association to a Suit whose name is Spades, and also have a Name with the value Ace. More simply, this query returns the suit of the Ace of Spades.

h2. Executing the Test Class

After the QueryRunner class and example CQL query have been created, we can use them together to query the remote data service and retrieve results.

h3. Execution Within Eclipse

Since Eclipse automatically compiles classes when the associated java source files are saved, there is no need to recompile the service. If you are not using Eclipse, run the following command to rebuild the service, including the QueryRunner class:

{terminal}
cd C:\caGrid\generatedServices\Sdk4Example ant clean all
{terminal}

Once compiled, the QueryRunner can be invoked. In Eclipse, right-click the QueryRunner class file, and select '''Run As->Run...''' to bring up the Run dialog. Click the '''New Launch Configuration''' icon in the upper right. The name of the run configuration, the project name, and Main class name will automatically be populated.{attached-image:tablealign=center|attachmentname=Data_Services_SDK_4_Tutorial_Run_Configuration.png} Change to the '''Arguments''' tab to specify the command line arguments which will be passed to the QueryRunner's main method. In the '''Program arguments''' text field, enter the following two items, separated by a single space:

* [http://localhost:8080/wsrf/services/cagrid/Sdk4Example]
** This is the URL of the tutorial grid service, as deployed in the local Tomcat installation
** If the container's port is different than the default, change ''8080'' to match it
* exampleCqlQuery.xml
** This is the CQL query from earlier in the tutorial. It will be executed by the data service.

Finally, click the '''Run''' button to save this configuration and execute the QueryRunner class. As the class executes, any messages from it will be printed to the console. When complete, the console should appear similar to the following:

{noformat}
Querying
Iterating
-- RESULT --
<ns2:Suit name="Spade" id="1" xmlns:ns2="gme://caCORE.caCORE/4.0/gov.nih.nci.cacoresdk.domain.other.levelassociation"/>
Done
{noformat}

h3. Execution Outside Eclipse

The QueryRunner class can be executed without Eclipse by means of a simple Ant build script. Copy the following into a file named '''queryRunnerExec.xml''' and place it in the root directory of the tutorial service:

{code}
<?xml version="1.0"?>
<project default="run" name="Query Runner Execution File" basedir=".">

<!-- Define the environment variable -->
<property environment="env" />

<!-- globus dir -->
<property name="ext.globus.dir" value="${env.GLOBUS_LOCATION}" />

<!-- Important directories and files -->
<property name="lib.dir" value="${basedir}/lib"/>
<property name="build.lib.dir" location="${basedir}/build/lib"/>
<property name="globus.lib.dir" location="${ext.globus.dir}/lib"/>

<target name="run" description="Runs the QueryRunner class from the caGrid 1.2 Data Services with caCORE SDK 4.0 tutorial">
<java classname="org.cagrid.sdk4.example.tutorial.QueryRunner"
args="${service.url} ${cql.file}">
<classpath>
<fileset dir="${build.lib.dir}">
<include name="**/*.jar"/>
</fileset>
<fileset dir="${lib.dir}">
<include name="**/*.jar"/>
</fileset>
<fileset dir="${globus.lib.dir}">
<include name="**/*.jar"/>
</fileset>
</classpath>
</java>
</target>

</project>
{code}

To use the build file, execute the following in the base directory of the service:

{terminal}
ant -f queryRunnerExec.xml -Dservice.url=http://localhost:8080/wsrf/services/cagrid/Sdk4Example -Dcql.file=exampleCqlQuery.xml
{terminal}

When run, the output should be similar to the following:

{noformat}
Buildfile: queryRunnerExec.xml

run:
[java] The args attribute is deprecated. Please use nested arg elements.
[java] Arg: http://localhost:8080/wsrf/services/cagrid/Sdk4Example
[java] Arg: exampleCqlQuery.xml
[java] Querying
[java] Iterating
[java] -- RESULT --
[java] <ns2:Suit name="Spade" id="1" xmlns:ns2="gme://caCORE.caCORE/4.0/gov.nih.nci.cacoresdk.domain.other.levelassociation"/>
[java] Done

BUILD SUCCESSFUL
Total time: 7 seconds
{noformat}

h2. Conclusions

These results indicate the data service retrieved a single Suit instance matching the query criteria. Changing the CQL query passed to the QueryRunner will change the output as the data service locates different objects.