Browse Prior Art Database

Using Mapping Metadata to Integrate Service Data Objects (SDO) Data Sources

IP.com Disclosure Number: IPCOM000171743D
Original Publication Date: 2008-Jun-18
Included in the Prior Art Database: 2008-Jun-18
Document File: 2 page(s) / 29K

Publishing Venue

IBM

Abstract

Using Mapping Metadata to Integrate Service Data Objects (SDO) Data Sources

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 54% of the total text.

Page 1 of 2

Using Mapping Metadata to Integrate Service Data Objects (SDO) Data Sources

SDO background: Service Data Objects (SDO) Data Mediator Services (DMS) are responsible for creating DataObjects based on data contained in data sources (backend systems), and then to update data sources based on Data Objects sent to them for updates. DMSs would typically have metadata associated with them, representing the metadata of data sources they can access in a format that can be understood by other SDO DMSs and clients (e.g., XML Schema).

SDO DataObjects are contained in DataGraphs.

Reference: Service Data Objects @ JCP: http://www.

jcp.org/en/

Problem statement: How can data sources be integrated so that SDO DataObjects contain information coming from distinct back ends?

Known solutions: The typical approach for working with common object types that come from more than one backend is to first use backend-specific DMSs that produce instances of their own metadata, (that is, their own view of the type). For example, a DMS for a SAP backend might produce an instance of class SAPCustomer, which conforms to the SAP system's structure for a customer:
Customer instances are accessed by first retrieving instances of the application specific types, SAPCustomer and PsftCustomer, from their corresponding DMSs, and then in a higher level application (possibly a "Super DMS") instantiate the generic instance and populate it with the data from the other two objects.

SAPCustomer {

first

last

cust

_ID : int

age: int

... }

Another DMS, (e.g., PeopleSoft*) might have a view of customer, something like this:

PsftCustomer {

name : string

customer

no : int

The usual approach for working with these types in an integrated application, is to define a third class, e.g....