OData Support in SQL Anywhere 16

Former Member · ‎06-12-2013

Introduction

OData is quickly becoming the Lingua Franca for data exchange over the web. The OData standard defines a protocol and a language structure for issuing queries and updates to remote data sources, including (but not limited to) relational databases, file systems, content management systems, and traditional web sites. It builds upon existing Web technologies, like HTTP and RESTful web services, the Atom Publishing Protocol (AtomPub), XML, and Javascript Object Notation (JSON).

SAP and Sybase iAnywhere released SQL Anywhere version 16 in March 2013, and it had many cool new features. This blog post will cover one specific enhancement, the new support for OData access to SA databases.

Note: SA 16.0 is the follow-on release to version 12.0.1. There was no version 13, 14, or 15.

Background

SQL Anywhere actually introduced support for SOAP and REST-based web services back in their version 9.0 release! To enable web access, the server needed to be started with a new commandline switch that started an internal HTTP listener. This allowed the database server itself to function as a web server, and it could handle incoming HTTP/s requests. Inside the database, the developer would create separate SERVICE objects that could take a regular SQL query against a table, view, or stored procedure, and transform the result set into a number of formats, including XML, HTML, and JSON. Figure 1 below shows that basic architecture. ODBC/JDBC client/server connections would come into the server on a TCP/IP port, and HTTP/S connections would arrive through a separate port and be processed by the HTTP listener.

While this was a nice feature, it had the following negative aspects:

Even though the HTTP web server component was listening on a separate port from the ODBC/JDBC connections, it still meant opening a port through the firewall and exposing the actual database server process to the open internet. Network administrators typically have a problem with opening non-standard ports through their firewall, especially to critical resources like database servers...
The SERVICE objects were separate database objects from the underlying tables, views, and procedures that they were exposing. These would be written in a specific SQL Anywhere syntax, and would have to be maintained separately. Changes to the schema were not automatically reflected in the service objects, including artifacts like the WSDL for any SOAP services.
The URI for accessing these services would need to include the physical database name. For example:

http://<servername>:<port>/<database name>/<service name>

This is a key piece of information that could potentially be used for malicious attacks against the database server.

SA 16.0 Architecture

SA 16 introduces a new server process for providing OData support. Its name is DBOSRV16.EXE, and it consists of two distinct components:

The DBOSRV16.EXE HTTP server, which is the Jetty open source Java servlet container. This process runs outside the SA16 database server, and listens for incoming HTTP or HTTPS connections from web clients.
The OData Producer Java servlet. This opens a JDBC connection to the SQL Anywhere database, and is responsible for processing the OData queries and updates and responding with either AtomPub (XML) or JSON formatted result sets. The OData producer servlet code is provided, and can be compiled and executed inside any web server capable of running Java servlets.

The best feature of this new setup is that database objects (tables and views) are automatically exposed to the OData producer. There is no longer any need to create and maintain separate SERVICE objects. In addition, the HTTP requests are not hitting the database server directly, increasing the security protection of that critical resource.

It's important to know that this does not replace the existing web services infrastructure - that all still exists in SA 16. These features are new additions to the architecture. Figure 2 below shows the revised architecture, with the DBOSRV16.EXE process managing incoming web requests.

Getting Started

The first step is obviously to install and license SA 16. (SAP has continued the practice of offering free developer licenses for SQL Anywhere.)

There is already an important service pack release posted on the Sybase Downloads site. Download and patch to a minimum of build 1535. Full documentation of SQL Anywhere 16 (and all prior releases...) can be found online at the CommentExchange site.

The SA 16 Samples folder gets installed into the \Users\Public\Documents\SQL Anywhere 16 folder. From there, the OData samples can be found in the \SQLAnywhere\ODataSalesOrders and \SQLAnywhere\ODataSecurity folders.

Open the start_server.bat file in the \ODataSalesOrders folder. The key line in this file is the one that launches DBOSRV16.EXE:

start "dbosrv16" "%__SABIN%\dbosrv16" SalesOrdersConfig.properties

That loads the new DBOSRV16.EXE process, using configuration options stored in the file "SalesOrdersConfig.properties". For the purposes of this exercise, the pertinent options in that file are the HTTP listener port, and the authentication style. This example uses port 8090, and a generic userid/password to connect to the SA16 Sample database. There are several other configurable options, including SSL certificates, logging file location and verbosity, and database authentication options.

Run the start_server.bat file to start the DBOSRV16 OData server.

Running OData Queries

My browser of choice is Google Chrome, but Firefox works as well for testing the OData connection. Enter the following URL, which is called the "service root":

http://localhost:8090/odata

The result is known as the Service Document, and it describes the set of entity collections that can be queried from a service. Take note that this is every table in the SA16 sample database that has a primary key. We'll cover how to include views and tables that do not have a primary key in the next section.

Append the /$metadata directive to get the Metadata Document, which defines all data exposed by the service as an XML schema.

http://localhost:8090/odata/$metadata

To query any individual entity, append that entity name to the service root. Here's how to query the Products table, and return the XML structure:

http://localhost:8090/odata/Products

If you'd rather see that response in JSON format, add the $format directive (note the "?" following the Products entity name, which serves as the separator between the entity URI and the query options):

http://localhost:8090/odata/Products?$format=json

OData contains an entire set of query options that function much like SQL clauses.

$format - select either json, xml, or atom as the structure of the returned data
$select - to select specific attributes (i.e., columns) from the entity (i.e., table).
$orderby - to sort on a specific attribute
$filter - functions the same as the WHERE clause in SQL
$top - restricts the result set to the first N rows retrieved
$skip - if the skip value is set to N, then the first row retrieved will be N+1
$expand - this can include nested subquery results to linked entities, when a specific foreign key is present

OData Producer Service Language (.OSDL) files

By default, the OData Producer servlet will expose every table and view that the connected user has SELECT authority for. In addition, the table must have a defined primary key. Since views do not have a primary key, they are not automatically included in the OData service document. To expose a view or a table without a primary key, an .OSDL file must be created and specified in the server startup .properties file.

The \samples\SQLAnywhere\ODataSecurity folder contains an example of an .OSDL file. Basically, it's a listing of the tables and view names, along with the column names that serve as the primary key of the entity. If you use an .OSDL file, then you must specify every table or view that is to be exposed in the service document. To illustrate, the sample secureView.osdl file only contains a single entry for the view EmployeeConfidential, so that is the only entity that is exposed by the OData producer.

Conclusion

The new OData Server process in SQL Anywhere 16 has a great many potential benefits.

It can speed the development and prototyping phase, by allowing quick creation and modeling of OData services, without requiring heavy backend or EIS development.
It can enhance the security of a production web services environment by eliminating the need for HTTP access directly to the database server.
It can reduce the overall complexity of an n-tier application by eliminating the need to write middle-tier components that do nothing but transform data into JSON or XML.