Programming model overview

WPAI mediators provide a uniform data-programming model across heterogeneous data sources. The model is based on JSR 235 - Service Data Objects (SDO) and Mediators.

SDO is a specifications for a programming model that not only provides uniformity among data sources, but also: More information on SDO can be found at http://www.eclipse.org/emf
Mediators are components that provide access to a specific data source type. They create SDO Data Graphs by reading data from the back-end, then propagating updates to the Data Graphs back to the back-end. Mediators need to be configured to provide the desired functionality. This configuration information is referred to as the mediator's metadata. The metadata contains a variety of information such as:

Application Control flow

Applications use the metadata objects along with connection information for the back-end to instantiate mediator objects (or commands). A mediator instance uses its metadata to determine the parameter it takes (as an SDO DataGraph) as input and the query results it generates (again as an SDO DataGraph). If the mediator allows users to modify the query results and applies the changes to the back-end, then it provides information about the changes as an SDO DataGraph. If any of the steps mentioned above cause the back-end to throw an exception, a fault DataGraph containing the error information is provided.

Elements of the programming model

  • Metadata: All metadata object types (for the various data source types) are derived from a base type, namely, com.ibm.wps.mediator.CommandMediatorMetaData. A particular metadata object is uniquely identified by a qualified name which consists of a name and a namespace. This is usually specified by the user when the metadata object is constructed.
  • Mediator: All commands are derived from a base type, namely, com.ibm.wps.mediator.CommandMediator. A CommandMediator object is instantiated using a CommandMediatorMetaData object. A CommandMediator is a stateless object (more like a stateless service). It may be reused when the user needs to invoke the same task with the same or different parameters.

    Every supported back-end data source type, implements a CommandMediatorFactory interface (com.ibm.wps.mediator.CommandMediatorFactory) that allows applications to instantiate commands from CommandMediatorMetaData objects. The methods in the CommandMediatorFactory interface also take other paramaters that contain connection information for the data source.

    The important methods in the CommandMediator interface are described below. Note that some of these methods may not be valid for certain back-ends.
    1. getParamDataGraph() - This method is used to get an empty parameter data graph. The parameter data graph that is obtained is then filled with the values of the parameters for a specific query.
    2. getDataGraph() - The method is used to obtain the results of a query or the output arguments of a function. This method optionally takes a parameter data graph that contains the parameters of the query or the input arguments of a function.
    3. getEmptyDataGraph() - This method is used with a CREATE type of CommandMediator to get an empty main data graph that will be populated with data for a new object. Once the user populates the empty data graph with the appropriate values, a call to the applyChanges method will create a new object in the back-end.
    4. applyChanges() - This method is used to propagate any changes made to the main data graph by the application. Some CommandMediator types, such as one that only retrieves information, do not implement this method as they do not propagate changes to the back-end.
  • SchemaMaker: Another interface of importance is the SchemaMaker (com.ibm.wps.mediator.SchemaMaker). The SchemaMaker is an object that determines the shape of the following data graphs from the CommandMediatorMetaData object passed to it:
    1. The structure of the SDO DataGraph that a mediator takes as input called the parameter data graph, such as parameters to a query or input arguments to a function.
    2. The structure of the SDO DataGraph that a mediator generates as the result of a query or the output arguments of a function call. This is the main data graph.
    3. The structure of the SDO DataGraph that a mediator generates as a result of a user request to save any changes made to the main data graph. This is called the output data graph.
    4. The structure of the SDO DataGraph that a mediator generates as a result of an exception during back-end interaction. This is called the fault data graph. The fault data graph is embedded in the MediatorException (com.ibm.wps.mediator.MediatorException) thrown by the Mediator.
    The structure of a DataGraph is expressed as the EClass (see http://www.eclipse.org/emf for more information on the Eclipse Modeling Framework) of the root data object of the data graph.
Related concepts
SAP data access
Siebel data access
PeopleSoft data access
Related tasks
Setting up SAP development environments
Adding SAP service data objects
Adding Siebel service data objects
Adding PeopleSoft service data objects

(C) Copyright IBM Corporation 2002, 2005. All Rights Reserved.