Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Difference between revisions of "EclipseLink/UserGuide/DBWS/Overview"

(Configuration)
(Configuration)
Line 24: Line 24:
 
The metadata for an EclipseLink DBWS service is contained in an easy-to-read service descriptor file <b>eclipselink-dbws.xml</b>:
 
The metadata for an EclipseLink DBWS service is contained in an easy-to-read service descriptor file <b>eclipselink-dbws.xml</b>:
 
* contains <b><i>name of EclipseLink DBWS service</i></b>
 
* contains <b><i>name of EclipseLink DBWS service</i></b>
* contains <b><i>name of sessions.xml</i></b> - if not present, then ''''<tt>eclipselink-dbws-sessions.xml</tt>'''' will be used
+
* contains <b><i>name of sessions.xml</i></b> - if not present, then <tt>'eclipselink-dbws-sessions.xml'</tt> will be used
 
* operation definitions
 
* operation definitions
 
* contains <b><tt>eclipselink-dbws-schema.xsd</tt></b> XML Schema Definition file
 
* contains <b><tt>eclipselink-dbws-schema.xsd</tt></b> XML Schema Definition file

Revision as of 14:45, 13 March 2009

EclipseLink DBWS Overview

The goal of EclipseLink DBWS is to enable simple and efficient access to relational database artifacts via a Web service, extending EclipseLink's core capabilities while leveraging existing components (ORM, OXM).

EclipseLink DBWS has two parts: a design-time tooling component (DBWSBuilder) and 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 be comprised of any number of operations of which there are 4 types:

  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)

The XML documents used by an operation conform to an XML Schema Definition (.xsd file).

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

The metadata for an EclipseLink DBWS service is contained in an easy-to-read service descriptor file eclipselink-dbws.xml:

  • contains name of EclipseLink DBWS service
  • contains name of sessions.xml - if not present, then 'eclipselink-dbws-sessions.xml' will be used
  • operation definitions
  • contains eclipselink-dbws-schema.xsd XML Schema Definition file

Example DBWS Service descriptor file

<?xml version="1.0" encoding="UTF-8"?>
<dbws
  xmlns:xsd="http://www.w3.org/2001/XMLSchema"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  >
  <name>example</name>
  <query>
    <name>countEmployees
    <result>
      <type>xsd:int</type>
    </result>
    <sql><![CDATA[select count(*) from EMP]]></sql>
  </query>
</dbws>

The information required by the EclipseLink DBWS service descriptor file is kept to a minimum and omitted fields have simple defaults, allowing for both auto-generation by tools or manual editing.

XML Schema Definition

An EclipseLink DBWS service requires an XML Schema Definition file to specify how information returned from the database is to be shaped. The EclipseLink OXM Project handles converting information from the database to XML, giving the user access to the complete range of EclipseLink Object-to-XML mapping capabilities.

An example of an auto-generated XML Schema

The design-time tool derives element-tag names from Database table metadata (column names, types, nullable, etc):

OWNER TABLE_NAME COLUMN_NAME DATA_TYPE DATA_LENGTH DATA_PRECISION DATA_SCALE NULLABLE
SCOTT EMP EMPNO NUMBER 22 4 0 N
SCOTT EMP ENAME VARCHAR2 10 (null) (null) Y
SCOTT EMP JOB VARCHAR2 9 (null) (null) Y
SCOTT EMP MGR NUMBER 22 4 0 Y
SCOTT EMP HIREDATE DATE 7 (null) (null) Y
SCOTT EMP SAL NUMBER 22 7 2 Y
SCOTT EMP COMM NUMBER 22 7 2 Y
SCOTT EMP DEPTNO NUMBER 22 2 0 Y
<?xml version="1.0" encoding="UTF-8"?>
<xsd:schema
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xmlns:xsd="http://www.w3.org/2001/XMLSchema"
  >
  <xsd:complexType name="empType">
    <xsd:sequence>
      <xsd:element name="empno" type="xsd:int" xsi:nil="false"/>
      <xsd:element name="ename" type="xsd:string" xsi:nil="true"/>
      <xsd:element name="job" type="xsd:string" xsi:nil="true"/>
      <xsd:element name="mgr" type="xsd:int" minOccurs="0" xsi:nil="true"/>
      <xsd:element name="hiredate" type="xsd:dateTime" xsi:nil="true"/>
      <xsd:element name="sal" type="xsd:decimal" xsi:nil="true"/>
      <xsd:element name="comm" type="xsd:int" minOccurs="0" xsi:nil="true"/>
      <xsd:element name="deptno" type="xsd:int" xsi:nil="true"/>
    </xsd:sequence>
  </xsd:complexType>
  <xsd:element name="emp" type="empType"/>
</xsd:schema>

Simple XML Format (SXF)

The design-time tools will not generate an XML Schema Definition when the information returned by a query operation has no easy-to-predetermine structure:

  • resultSet from a custom SQL query operation
  • results from a Stored Procedure query operation
  • updated row-count from an update operation
<?xml version="1.0" encoding="UTF-8"?>
<xsd:schema
  xmlns:xsd="http://www.w3.org/2001/XMLSchema"
  >
  <xsd:complexType name="simple-xml-format">
    <xsd:sequence>
      <xsd:any minOccurs="0"/>
    </xsd:sequence>
  </xsd:complexType>
</xsd:schema>

The EclipseLink DBWS runtime provider uses information only available at the time of query execution to build XML element-tag names; thus, these XML documents are 'dumb' as they cannot be validated against any schema - or more accurately, only the 'sequence-of-any' schema above can validate the documents.

Element tag names are direct copies of table's column names:
<?xml version = '1.0' encoding = 'UTF-8'?>
<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>



Back to the top