The following topics describe the data services configuration language and the key elements used when composing a data service, such as queries, databases, operations etc. along with example syntax.
Table of Contents maxLevel 3 minLevel 3
Data services and resource language
Data services and resources are defined using the Data Services and Resource Language (DSRL) where a <data> element describes a data service or a resource. The common attributes of a <data> element is given in the following example:
To create a data service using the management console, see Developing Data Services.
Configuring the database
The following sample config gives the common elements used to connect to a database:
To create a datasource to connect to a database using the management console, see Creating Datasources .
A query consists of parameters and it describes how to map the result to an XML element. It is similar to a function that maps some parameters to an XML element. A query's definition does not indicate how the parameters are acquired. Instead, it just lists the parameters that are needed, assuming that the parameters will be provided. If the query is at a top level (i.e., direct child of <data>) then either an operation definition or a resource definition provides the context for the parameters. If the query is nested within a <result> element, then the parameter names refer to column names of the result table described in the <result> element of the XML.
To create data service queries using the management console, see Writing Data Service Queries.
Defining service operations
Operation refers to a Web service operation defined by a query. The operation is defined as an invocation of a query indicating how the parameters of the query are computed or derived. The syntax is as follows:
To define data service operations using the management console, see Defining Service Operations.
<resource path="uri-template" method="GET|POST|PUT|DELETE" disableStreaming="xs:BOOLEAN"> <description>"xs:string"</description> <call-query href="xs:IDREF" /> <with-param name="xs:NMTOKEN" /> query? </call-query> </resource>
To create REST resources using the management console, see Exposing Data as REST Resources.
Defining event trigger
<event-trigger id=xs:NCName" language="XPath"> <expression>xs:string</expression> <target-topic>xs:string</target-topic> <subscriptions> <subscription>xs:string</subscription> </subscriptions> </event-trigger>
- event-triger/@id: REQUIRED id used to identify the event-trigger, used in data services queries.
- event-triger/language REQUIRED currently only XPath is supported as the event trigger language.
- target-topic REQUIRED topic, to which the event notifications will be published.
- subscriptions REQUIRED can be any WS-Eventing complient endpoint. For example, an SMTP transport can be used to send a message to a mail inbox, where an email address is given as the subscription. Here many subscriptions can be defined for the given topic.
When a data service receives messages, it expects to receive a signed and encrypted message as specified by the security policy stored in the registry of your server. Therefore, as shown below, you can embed the security configurations directly in the .dbs file of the data service by adding the path to the relevant security policy. Please see Apache Rampart and Axis2 documentation on the format of the policy file. You can also use the 'engageSec' element to ensure that Apache Rampart is engaged for the data service.
<policy key="sec_policy"/> <enableSec/>
Sample data service configuration
Given below is a sample data service configuration with queries, resources etc. for your reference: