WHITE PAPER
Web Services for Database Access
Data Service Abstraction
C++, Java, or mixed languages
Hugh Wayham
www.roguewave.com

WHITE PAPER
Abstract
A Data Service may be implemented as a web service to multiple data sources, providing a standard
interface to a database or wherever data may reside. There are several advantages:
» Liberate Data: Provide an API to critical data which is locked in proprietary applications
» Provide Consistency: A service may be shared by many applications and developers, providing a
common view of data to different applications, and avoiding the duplication of data
» Protect Integrity: Ensure proper business rules, transactionality, and safe data access
» Ease of Maintenance: SQL is centralized and more easily modified
» Stabilize Data Schema: The DBA can concentrate on managing the database, while business and
process experts can write their applications to services which are isolated from database changes
» Combine Data Sources: Non-SQL data such as XML, memory cache, or additional SOA layers are
combined and optimized outside the application, reducing complexity for the developer.
Rogue Wave® Hydra
Rogue Wave Software provides an integrated development and deployment framework for delivery of
both C++ and Java service-based applications called Hydra. Rogue Wave® Hydra may be used with
a framework for database access called SourcePro® DB. More information can be found at http://
roguewave.com/products/hydra/
Using a Service for Data Abstraction
Many businesses and applications are data-centric, and information is a key asset. As business and
applications evolve, the data and requirements for this data grow with it. Applications which use this data
may require additional capabilities, which are not addressed in a convenient API. Given that accessing these
valuable assets is a way IT provides a business value to the enterprise, one solution may be to access the
data directly using SQL. Using SQL to access current application databases quickly runs into several issues:
» Expert Data Knowledge Required: The complexity and volume of information dictates careful
study before application development can begin.
» Data is not Static: As data structures undergo change, it can be a huge task to maintain the SQL.
» Applications are Intertwined: “No application is an Island”. Applications have interdependencies,
forcing unrealistic, simultaneous changes to all applications when anything changes in the data layer.
«2» www.roguewave.com

WHITE PAPER
» Data and Business Rules must be enforced: The rules governing data can be as important as the data
itself. If a new application violates transactionality or data relationships, it can break other systems.
A solution is to provide a centralized interface to data as a service. Development and maintenance of such
services can be performed by those with the responsibility and knowledge required to ensure consistency.
The data API can be exposed directly or through an ESB to multiple applications and developers. The
SQL implementation is “hidden” to allow for safe and widespread use. The service can be optimized
by data experts, and scaled with hardware by employing multiple servers and services as required.
Applications from business intelligence to transactional systems, using a variety of methods (e.g.: direct
clients, batch processes, portals or other services), can utilize a consistent data API.
Web Services and Service Oriented Architecture
Before we get into the specifics of SQL, let’s define the context in which this document refers to Service
Oriented Architecture (SOA). SOA interfaces are reusable APIs which are technologically agnostic and
language independent. Web services are a technology instantiation of SOA that use core specifications
such as SOAP and WSDL. Hydra supports Web services as well as other transports and protocols which
can be used to implement a SOA system. The remainder of this paper will refer to “Web service”, but
«3» www.roguewave.com

WHITE PAPER
please know that you may instead implement a proprietary message format and transport mechanism
other than core Web Service specifications.
Web Services for Database Access
Web services for database access are a good architectural case for Web Services. It eliminates a “brittle”
or inflexible data interface, which can become a performance bottleneck. In contrast, embedding SQL
within an application represents a point-to-point integration with multiple products and applications and
presents a vulnerability.
Services provide the “what” and not the “how” to other applications. An example may be an API that
provides employee information based on Employee ID. If this is provided as a SQL request, that SQL
may require drastic changes if the company acquires another and must therefore combine multiple
sources. If this request is used in multiple applications in multiple locations, then the problem is
compounded by requiring multiple redundant changes. If a Web service is employed, a remote interface
manages the API centrally for one or more applications. It can implement and make changes to the
request (“the how”), without impacting the requesting application. This implementation can be fine tuned
by data experts and made available on scalable hardware to provide performance improvements in one
location that can have a corporate-wide impact.
Data Abstraction: Implementing the Data Service
SQL may be used to create a Data Service. The following steps are common to creating services of
any type:
» Describe any complex types (XSD)
» Describe the service (WSDL) and it’s “Interface”, using these complex types
» Code-generate the service, as well as a stubbed out implementation, using the WSDL
» Implement each “Operation” or method within the “Interface”, by SQL or other means
Web Service Definition Language (WSDL) is used to fully describe the “what” of a service. The WSDL
specifies: Interface, Data, Binding, and Server Address. The Interface includes the definitions of any non-
primitive or complex types, which are either defined in a separate XSD or directly within the WSDL.
An example might be a WSDL which describes and interface containing operations for “CustomerInsert”
and another one for “CustomerUpdate”. They both deal with the database table called “Customer”, and
«4» www.roguewave.com

WHITE PAPER
both refer to the entire row of data as an entity. Instead of managing the organization of several individual
columns which collectively define the database row, it might be useful to describe this row as a complex
type. This can ensure consistency.
<xsd:complexType name=”CustomerType”>
<xsd:sequence>
<xsd:element name=”Id” type=”xsd:int”></xsd:element>
<xsd:element name=”Name” type=”xsd:string”></xsd:element>
<xsd:element name=”Phone” type=”xsd:string”></xsd:element>
</xsd:sequence>
</xsd:complexType></xsd:schema></wsdl:types>
After defining a complex type which is your database row, it can then be more simply used in the
definition of any interface which requires it.
The WSDL or service definition is language agnostic. Your implementation might be in Java or C++, and
Hydra will generate all code necessary for either language. Hydra is based in Eclipse1 and offers a plug-
in that steps users through this process. Hydra will either accept a WSDL you have already prepared,
or create a standard WSDL that can be further modified. Based on this WSDL, it will code generate a
service with an empty implementation. Your task is then to implement the code to accept input (e.g.
“CustomerType”), perform a “data task” which most likely includes some SQL, and return an appropriate
response. A C++ example using Hydra and its SQL framework might be:
DBService::cn_ = getRWDBConnection();
RWDBOSql myQuery ( “Insert Customers….” );
myQuery.execute(DBService::cn_);
A full working code sample for Hydra is available on request.
The remainder of this paper will detail how Hydra can be used, with either Java or C++ and SQL, to
provide a scalable, data services interface.
Either Java or C++ May Implement the Data Service
The choice of language to implement a SQL-based service does not matter from Hydra’s perspective.
Your choice may be based on application requirements and available skills. While Hydra’s infrastructure
is implemented in C++, the service API is available with either C++ or Java bindings. Hydra supports
both equally well, but excels when a mixture of Java and C++ is required.
The C++ Eclipse (CDT) with the Hydra SOA plugins can work with your debugger and compiler of
choice (GCC and Visual Studio are most popular). However, the use of a modern IDE does not preclude
the use of other code editors and tools.
«5» www.roguewave.com

WHITE PAPER
The Java Eclipse user works in a very familiar IDE environment, and utilizes the same plugins as the
C++ user.
Optionally, you can construct “composites” from multiple “components” or classes. Hydra utilizes the
Oasis SCA standard to implement cross language “composites”, which allow Java and C++ classes to
directly invoke each other without JNI.
Java or C++?
JAVA C++
JDBC is the RDBMS interface, providing a common It is common to utilize the native CLI (Call Level
API to execute and evaluate SQL to multiple databases. Interface) specific to each RDBMS vendor.
This code is portable to multiple platforms, yet SQL As with Java, there may be differences in data-types
syntax and data-types vary between database vendors. between vendors, but additionally there are differences
This requires “two way” code and type conversions between platforms (e.g.: Unix vs Windows).
for portability.
SQL is still different between vendors, requiring “two-
All access is done through a standard JDBC interface, way” code.
but different RDBMS vendors may support different
methods and optimizations. For example, writing Using the CLI directly is more complex than using
portable code may involve complex code with methods JDBC, but can be more efficient. As with Java, each
such as storesMixedCaseQuotedIdentifiers() and vendor’s CLI may support different optimizations.
supportsLimitedOuterJoins().
While you can certainly use the traditional methods described above with Hydra, a third alternative is
available for C++. Hydra provides a JDBC-like interface which is more portable than JDBC, yet offers
the performance advantage of a native CLI.
The remainder of this paper will compare and detail a C++ API called SourcePro® DB , which includes
two interfaces: SQL and Class-based. As with Java, this provides portability between operating systems
with a less complex interface than the native CLI. Unlike Java, SourcePro® DB may have better
performance and be more portable between RDBMS vendors.
SourcePro® DB: “JDBC for C++”
Decisions on data handling effect development and maintenance costs, and have the potential to “lock in”
a particular database implementation. ODBC is a commonly used API with the goal of vendor neutrality,
but it is not always accomplished. The subset API implemented by ODBC driver software can vary in
«6» www.roguewave.com

WHITE PAPER
behaviour and functionality. JDBC is restricted to 1992 ANSI SQL and is Java only. A third alternative
is for the developer to use the database-specific “native” call level interface (CLI) provided by each
database vendor for increased performance and functionality. In addition to vendor lock-in, these “C”
APIs are quite low level, requiring much code devoted to repetitious tasks such as error handling, thread
communication, connection pool management, and implementing various SQL best practices.
SourcePro® DB provides database and operating system portability, implements SQL best practices
and common tasks through a framework, and often achieves the performance and functionality of the
native call level interface. It does this through a class-based implementation, presenting a common API
regardless of database vendor. It implements a generic API using higher level classes which “wrap” the
native CLI provided by each vendor, but also allows you to get as low-level as is required. In this way it
is portable and full featured, but provides a higher-level interface without ODBC restrictions.
What’s wrong with ODBC?
ODBC has been a popular database abstraction since 1992, offering a consistent C-based API which
accepts SQL statements. It is implemented by a wide variety of third party drivers. While the API is
consistent, SQL is not. Additionally, few drivers implement the full (or same) ODBC API and will likely
have different behavior runtime characteristics. Common problems include:
» Applications must restrict SQL syntax to a “lowest common denominator” supported by all required
database vendors and ODBC drivers, or write “two way code” to adjust for these differences.
» Drivers are OS dependent, so different code may be required for different platforms -- perhaps even
for the same database.
» Strictly a data access API, with no “best practice” implementation of common tasks.
- Optimal buffer/memory allocation, using a reader/writer cache, multithreading, utilizing asynchro-
nous database calls to perform other work while waiting for IO, and exception safe coding, are all
left up to the developer.
» Poor performance
» Inconsistent error handling behavior
«7» www.roguewave.com

WHITE PAPER
SourcePro® DB
Rogue Wave® SourcePro® DB extends a database vendor’s native call level interface (CLI) using a JDBC
like SQL interface. Optionally, you can use a separate class-based interface. Each enables developers to
establish connections, perform queries, join tables, and insert, delete and update data using a less complex
C++ syntax. The implementation employs many best practices of data handling, threading, and exception
handling, allowing the developer to focus on their particular SQL and data APIs. SourcePro® DB is
available on over 50 operating system/compiler environments, providing a portable C++ framework.
SourcePro® DB consists of:
» An Interface Module which provides a single programming application interface for all database
vendors. The developer programs to this RDBMS neutral API.
» The vendor neutral Interface module links with and points to Access Modules, which provide
concrete implementations using specific relational databases. These access modules transparently
use the RDBMS vendor specific APIs. The developer does not deal directly with an access module
API. These modules support all major vendors, including: DB2, Informix, Microsoft®2 SQL Server,
MySQL®3 Server, PostGreSQL, Oracle®4, and Sybase®5.
1
Microsoft and Visual Studio are either registered trademarks or trademarks of Microsoft Corporation in the
United States and/or other countries
2
MySQL is a registered trademark of MySQL AB in the United States, the European Union and other countries.
3
Oracle is a registered trademark of Oracle Corporation and/or its affiliates.
4
Sybase is a registered trademark of Sybase Inc. and/or its affiliates.
«8» www.roguewave.com

WHITE PAPER
The layered design of SourcePro® DB allows developers to concentrate on what is done rather than how.
Although portability is a major strength, productivity is increased as complexity is reduced.
A Comparative Example: JDBC vs SourcePro® DB
In this example, the same operation is performed using different implementations. The operation to be
performed is selecting data from a table and printing out each row.
Table 1. Schema for table used in the example.
COLUMN NAME DATATYPES
ID NUMBER
Name VARCHAR (30)
Percent Float
You should find similarities between JDBC and SourcePro® DB ’s OpenSQL interface. They are both
portable to different platforms, yet both are not strictly portable between RDBMS vendors (unlike the
alternate Class-based interface of SourcePro® DB).
Hydra supports both Java and C++, so either may be used.
Step 1: Obtain a connection
JDBC SOUrCEPrO® DB
Connection c = DriverManager. RWDBDatabase c =
getConnection( RWDBManager::database(
dbURL, userid, password); accessmodule, host, userid,password);
Step 2: Create and Execute SQL and return a result
JDBC SOUrCEPrO® DB
Statement s = c.CreateStatement(); RWDBResult r = c.executeSql(
ResultSet r = s.ExecuteQuery( “select * from TABLE1”);
“select * from TABLE1”); RWDBReader reader = r.reader();
«9» www.roguewave.com

WHITE PAPER
Step 3: Iterate through the result, printing columns
JDBC SOUrCEPrO® DB
While(r.next() ) { while (reader()) { reader >>
myInt = r.getInt(“ID”); myInt >> myString >> myPercent;
myString = r.getString(“Name”);
myPercent = std::cout <<
r.getFloat(“Percent”); myInt << myString <<
myPercent <<
System.out.println( std::endl;
myInt + myString + }
myPercent);
}
Class-Based (Vendor Portable) Interface: Something you won’t find
in JDBC
Let’s examine SourcePro® DB’s class-based interface. Again, you may use either the JDBC-like SQL
interface presented above, or the alternative described below. The Class-based interface is more portable
and may result in simpler code by implementing database access without SQL. Since the templatized
class itself will implement SQL differently for different RDBMS vendors, it is portable. If you are more
comfortable with C++ than with SQL, it may also be easier to implement.
(Step 1 and 3 are identical to above)
Step 2: Create and Execute SQL and return a result
JDBC SOUrCEPrO® DB (NO SqL)
Statement s = c.CreateStatement(); RWDBTable t = c.table(“TABLE1”);
ResultSet r = s.ExecuteQuery( RWDBReader reader = t.reader();
“select * from TABLE1”);
Dynamic SQL, Complex SQL
Few applications simply use “select * ”, so how would we add a “where” clause? This interface can
accomplish complex joins and other SQL operations within the class-based paradigm. Here we show
building a “where” clause in modular fashion, using the “Selector” class.
« 10 » www.roguewave.com

WHITE PAPER
JDBC SOUrCEPrO® DB
Int myInt = 101; Int myInt = 101;
Statement s = c.CreateStatement(); RWDBTable t = c.table(“TABLE1”);
ResultSet r = s.ExecuteQuery( RWDBSelecter s = db.selector();
“select * from TABLE1 s.where(t[“ID”] =
Where TABLE1.ID=myInt”); RWDBBoundExpr(&myInt));
( No equivalent “Selector” capability ) s.execute(db.connection());
While the examples above have all retrieved data, equivalent methods exist for insert/delete/update and
even DDL (e.g.: CREATE TABLE) operations. This is intended to be a simple example. You might
create far more complex statements with either JDBC or SourcePro® DB . An important difference
between them is portability, SQL “best practice”, and common tasks such as threading, buffering, and
error handling. More complete code samples are available on request.
Let’s next explore the topic of error handling, which is sometimes a major portion of any SQL application.
Consistent Error Handling
Much code is devoted to handling failures, and there are many unforeseen conditions in database
applications which are outside the developer’s control. You might run out of space, have permission
problems, find bad data, or encounter network issues. Different databases have different error codes, not
to mention behaviors during an error condition. There are two problems: the laborious code involved, and
portability between database vendors or versions.
Both Java and C++ are object oriented languages which provide a TRY/CATCH convention to handle
error conditions. SourcePro® DB provides an exception handler to manage errors. Two messages are
available: a generic one across vendors, or the exact RDBMS error. The developer might iterate over
multiple messages and handle them safely. Unlike JDBC, SourcePro® DB additionally provides vendor
neutral error messages and handling.
JDBC SOUrCEPrO® DB
Try { Try {
// Some Database Access Code Here // Some Database Access Code Here
} }
Catch (SQLException e) { Catch (RWxmsg& e) {
System.out.println(e.getMessage()); Std::cout << e.why());
} }
« 11 » www.roguewave.com

WHITE PAPER
Summary
A service may be developed to “wrap” SQL or other data access, perhaps combining several sources or
complex data manipulation. Hydra and other tools may implement this with Java and JDBC, but that is
not the only solution. Hydra provides a database interface for C++ that is even more portable than JDBC,
yet may provide high performance and the ability to combine other C++ (as well as Java) APIs.
The main benefits of this approach are:
» Consistency: Reuse of data interfaces by multiple applications
» Maintainability: “Hiding” raw SQL implementations
» Combine/Optimize sources: Allow Experts in data to create sophisticated implementations
» Liberate Data: Provide an API for closed systems, by data access interfaces
» Integration: Using Service Oriented Architectures to integrate in a loosely coupled manner
» Scalability: Use a set of distributed interfaces to achieve throughput and failover by using
multiple implementations
Next Steps
View a short video covering service creation using Eclipse and C++:
http://www.youtube.com/watch?v=yKmlRW2HFCQ
Download a free evaluation:
http://www.roguewave.com/downloads
Build a Proof of Concept project
Contact Rogue Wave Software for support from an engineer: 1-303-473-9118.
USA 1-800-487-3217
FrANCE +33 (0)1
GErMANY +49 (0)6103 59340 Copyright © 2009, Rogue Wave Software, Inc. All Rights Reserved. Rogue Wave is
UK +44 8450 549950 a registered trademark of Rogue Wave Software, Inc. All other trademarks are the
www.roguewave.com property of their respective owners.