Jump to: navigation, search

EclipseLink/UserGuide/DBWS/Overview


EclipseLink DBWS

link="http://wiki.eclipse.org/EclipseLink"
EclipseLink
Website
Download
Community
Mailing ListForumsIRC
Bugzilla
Open
Help Wanted
Bug Day
Contribute
Browse Source

EclipseLink DBWS Overview

EclipseLink DBWS provides Java EE-compliant, client-neutral access to relational database artifacts via a Web service. EclipseLink DBWS extends EclipseLink's core capabilities while leveraging its existing ORM and OXM components.

EclipseLink DBWS includes two parts

  • A design-time component (DBWSBuilder)
  • A runtime provider component that takes a service descriptor (along with related deployment artifacts) and realizes it as a JAX-WS 2.0 Web service. The runtime provider uses EclipseLink to bridge between the database and the XML SOAP Messages used by Web service clients.

An EclipseLink DBWS service may include any number of the following operations:

  1. insert - inserts into the database persistent entities described by an XML document.
  2. update - updates database persistent entities described by an XML document.
  3. delete - removes from the database persistent entities described by an XML document.
  4. query - retrieves from the database persistent entities described by an XML document.
    Selection criteria for Query operations can be specified by:
    • custom SQL SELECT statement
    • Stored Procedure invocation
    • EclipseLink Named Query (that can use the complete range of EclipseLink ORM Expression Framework APIs)

XML-to-Relational Mapping (XRM)

EclipseLink's ORM and OXM features provides the basis for a powerful bridge between a database's relational structure(s) and XML's hierarchical structure.
XRRunTime.png

Configuration

A typical EclipseLink DBWS service is packaged in an archive (.jar or .war file) with a service descriptor file in the META-INF directory (or WEB-INF/classes/META-INF when packaged in a .war file). To bridge the relational database and XML worlds, an EclipseLink sessions.xml file points to two Eclipse projects - one for the ORM side, the other for the OXM side. The service also requires an XML Schema Definition file (.xsd) which in conjunction with the OXM project, specifies how information from the database is to be 'shaped' into XML.

root of archive  {not all files displayed ...}
 \---META-INF
   |   eclipselink-dbws.xml
   |   eclipselink-dbws-sessions.xml -- name can be overriden by <sessions-file> entry in eclipselink-dbws.xml
   |   eclipselink-dbws-or.xml
   |   eclipselink-dbws-ox.xml
   |   eclipselink-dbws-schema.xsd -- when deployed in a .war file, located in a different directory
EclipseLink DBWS Service descriptor file

The EclipseLink DBWS service descriptor file (eclipselink-dbws.xml) is easy to read with minimum required information and simple defaults for omitted fields, allowing for both auto-generation by a utility or manual editing. The service descriptor file is described in full in the User Guide.

<dbws xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
  <name>example</name>
  <sessions-file>example-dbws-sessions.xml</sessions-file>
  <query>
    <name>countEmployees
    <result>
      <type>xsd:int</type>
    </result>
    <sql><!--[CDATA[select count(*) from EMP]]--></sql>
  </name>
</query>
EclipseLink DBWS Sessions.xml file

The EclipseLink DBWS Sessions.xml file is described in full in the User Guide.

EclipseLink DBWS service schema file

The EclipseLink DBWS service schema file (eclipselink-dbws-schema.xsd) can be created by hand, or auto-generated by the DBWSBuilder utility which derives XML element-tag names from Database metadata (column names, types, nullable, etc).

Simple XML Format (SXF)

The DBWSBuilder utility will not generate a schema file when the information returned by a query operation has no pre-determined structure:

  • a resultSet from a custom SQL query operation
  • the results from a Stored Procedure query operation
  • the row-count from an update operation

In these cases, the EclipseLink DBWS runtime provider uses the resultSet's metadata to build the XML element tag names:

ResultSetMetaData rsmd = rs.getMetaData();
int colcount = rsmd.getColumnCount();
for (int i=1; i <= colcount; i++) {
    String elementName = rsmd.getColumnName(i).toLower(); //empno, ename, job ...
}
<simple-xml-format>
  <simple-xml>
    <empno>7788</empno>
    <ename>SCOTT</ename>
    <job>ANALYST</job>
    <mgr>7566</mgr>
    <hiredate>1987-04-19T00:00:00.000-0400</hiredate>
    <sal>3000</sal>
    <deptno>20</deptno>
  </simple-xml>
  <simple-xml>
    <empno>7369</empno>
    <ename>SMITH</ename>
    <job>CLERK</job>
    <mgr>7902</mgr>
    <hiredate>1980-12-17T00:00:00.000-0400</hiredate>
    <sal>800</sal>
    <deptno>20</deptno>
  </simple-xml>
</simple-xml-format>

These XML documents are 'dumb' as they cannot be validated against a schema - or more accurately, only the following very permissive 'sequence-of-any' schema can validate such documents:

Simple XML Format Schema
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema">
  <xsd:complextype name="simple-xml-format">
    <xsd:sequence>
      <xsd:any minoccurs="0"></xsd:any>
    </xsd:sequence>
  </xsd:complextype>
</xsd:schema>

The element tags simple-xml-format and simple-xml can be customized by setting the appropriate properties on an operation