Using Service Data Objects with Enterprise Information Integration technology

Combining Enterprise Information Integration (EII) technology with Service Data Objects (SDO) helps object-oriented programmers easily work with a wide variety of heterogeneous data sources and reduces the complexity of integrating disparate data. In this article, we explain why, describe a sample architecture, and provide coding examples based on early SDO support in IBM® WebSphere® Studio and EII support in WebSphere® Information Integrator.


C. M. Saracco (, Software Engineer, EMC

Cynthia M. Saracco is a senior software engineer at IBM Silicon Valley Lab. She has published two books and more than 40 papers on technologies related to database management, object-oriented programming, and Web technologies. In addition, she has lectured on these subjects thorughout North America, South America, Europe, and the Middle East. She can be reached at

Jacques Labrie (, Senior Software Engineer, EMC

author photoJacques Labrie is a senior software engineer at the IBM Silicon Valley Lab in San Jose, CA. Jacques has been a manager, team lead, and developer on multiple IBM warehousing and metadata products since 1984. Currently, Jacques is responsible for prototype development of integration scenarios with the IBM WebSphere family of products.

Stephen Brodsky, Senior Technical Staff Member, EMC

Stephen BrodskyStephen A. Brodsky, Ph.D., is a Senior Technical Staff Member at the IBM Silicon Valley Laboratory. He has led or contributed to numerous software architectures, products, and standards, including Service Data Objects (SDO), the IBM SWG Architecture Board SOA BluePrint, WebSphere and Rational Server and Studio products, the Eclipse Modeling Framework (EMF), UML, MOF, and XMI (XML Metadata Interchange). He has also co-authored a book on XMI. He holds a dozen patents on object technology and is a member of several SWG AB workgroups. You can contact Stephen at

01 July 2004

Since IBM and BEA Systems collaborated on a new Java™ data access specification last year, many IT architects and software engineers wonder how this new model, known as Service Data Objects or SDO, can be employed with Enterprise Information Integration (EII) technology, which has become increasingly popular during the last two years. Both SDO and EII offer programmers a single interface to a variety of disparate data, allowing programmers to manipulate this data through a single data structure. You will learn how both technologies can be used together in service-oriented architecture (SOA) applications that promote flexible business environments.

SDO and EII technologies form a complementary solution, because each differs from the other in key respects. SDO, for example, is a programming model that supports a disconnected application programming architecture, uses data graphs to represent persistent data, and employs an object-based API. EII, by contrast, is a data integration server that provides real-time data access, typically represents heterogeneous data as tables, and usually employs a SQL-based API.

Using EII with SDO provides SDO architects with increased capabilities and improved productivity, which you will learn in this article. EII can help SDO programmers quickly build and deploy a virtual data access services layer for front-end Java components.

In this article, we discuss the synergy between SDO and EII technologies, drawing on commercial implementations from IBM. We provide examples of using an early version of SDO included in WebSphere Studio Application Developer, Version 5.1.2 with EII technology supported by WebSphere Information Integrator, Version 8.1. For those unfamiliar with SDO or EII, we first provide a brief introduction to these technologies and explain the potential benefits of each. Next, you will an integrated architecture and provide sample code. Finally, we offer tips for successful design, development, and deployment of pilot projects using SDO and EII.

Technology overview

Service Data Objects

SDO is an object-based programming specification for uniform access to various forms of data. It is designed to complement existing Java 2 Enterprise Edition (J2EE™) data access mechanisms, including Enterprise JavaBeans (EJBs), Java Database Connectivity (JDBC™), and a number of popular frameworks for persistence. It is also intended to support service-oriented architectures (SOA), including Web services. Part of the motivation for defining SDO is to enable programmers and developers of programming tools to take advantage of a consistent, object-based API for data access while working within the development framework of their choice.

SDO features a disconnected programming model, which is a common requirement of many Web-based applications. SDO is well suited to applications that can benefit from connecting to a database (or other persistent data source), retrieving appropriate data, disconnecting from the data source, and processing or manipulating the data offline. Any updates to the in-memory copy of data can be applied later after the application re-establishes a database connection, and optimistic concurrency control techniques can detect and prevent conflicting updates. SDO provides programmers with an object-oriented way of modeling and manipulating a variety of persistent data without having to learn the native APIs of each required data source.

As shown in Figure 1, SDO programmers work with data graphs (collections of tree-structured data) that consist of one or more data objects. The data graph structure is well suited to certain types of Web applications, such as those that display master-detail information and is easily understood by most object-oriented application programmers. Figure 1 shows how application clients or components work with disconnected data graphs returned by one or more data mediator services, such as the JDBC mediator shown here.

At runtime, data mediator services are responsible for interacting with the appropriate data sources, constructing graphs from the retrieved data, and ultimately applying any changes made to the in-memory graphs back to the data sources. We'll concentrate on one particular type of data mediator service, a JDBC mediator, to illustrate how data can be retrieved from an EII server and manipulated offline through the resulting data graphs.

Figure 1. SDO programming model
SDO programming model

Enterprise Information Integration

EII technology provides programmers with a single-site image of disparate data that may be maintained in different formats, retrieved via different application programming interfaces (APIs), and managed by different remote servers. As such, it enables programmers to work at a higher level of abstraction than might otherwise be possible, as programmers perceive heterogeneous, remote data as though it all resided in a single, locally accessible database.

With EII, Java programmers typically write JDBC applications or applications using EJBs to connect to the EII server and manipulate a wide range of data. EII provides similar services to non-Java based applications, including those generated by 4GL tools as well as those written in procedural and object-oriented programming languages. Figure 2 illustrates a sample EII architecture. Client applications or components use JDBC or SQLJ to access disparate data managed by an EII server, which transparently integrates heterogeneous data and returns it in a tabular structure.

Figure 2. Sample EII architecture
Fig. 2

Most EII offerings share these characteristics:

  • Support for a variety of data sources, including relational database management systems (DBMSs), non-relational DBMSs, files, XML documents, and others
  • SQL-based API
  • Ability to join, union, aggregate, and otherwise correlate data from multiple sources in a single query
  • Ability to create individual views or virtual data objects based on data integrated from multiple sources
  • Location transparency
  • Automatic data type conversion services
  • Real-time programming model

EII technology is sometimes referred to as "federated data services" or "federated database technology" in literature.

Commercial implementations

A number of vendors have announced or shipped support for SDO, EII, or both. IBM is among these, and this article uses IBM's commercial implementations of SDO and EII to show how these two technologies can be deployed together.

WebSphere Studio Application Developer

An early version of SDO is included in WebSphere Studio Application Developer 5.1.2 and in WebSphere Application Server 5.1. (This early release of SDO is often referred to as "Web Data Objects" or "WDO.") The early release of SDO consists of various class libraries, including those for a JDBC data mediator service that is designed to support wizards for generating dynamic JavaServer Pages (JSPs) using SDO.

As mentioned earlier, we'll focus most closely on the JDBC data mediator service provided with WebSphere Studio. Like all data mediator services, the JDBC mediator expects programmers to identify the data they'd like retrieved. In addition, programmers must supply an active connection to the target JDBC database so the mediator can construct and execute the appropriate query.

Programmers create and populate a metadata object to identify the table (or view) they'd like retrieved. Inter-table relationships, primary key columns, and other information about the target data is specified through the metadata object as well. The JDBC data mediator service generates the appropriate SQL statements (SELECT, INSERT, UPDATE, and DELETE) to access the target data source.

The JDBC data mediator service supports access to a number of JDBC-enabled data sources and has been tested with DB2 UDB, Oracle, Cloudscape, and Microsoft SQL Server. Note that access to each database is performed through individual database connections that the programmer must establish. This is where WebSphere Information Integrator can extend and enhance the built-in capabilities of the JDBC data mediator: by using a single connection to WebSphere Information Integrator, the mediator can transparently return data integrated from multiple data sources, including additional relational databases, non-relational databases, and files.

WebSphere Information Integrator

WebSphere Information Integrator provides enterprise information integration services. It possesses all the characteristics of basic EII technology outlined earlier, as well as a number of advanced capabilities, including:

  • Global, cost-based query optimization services.
    This enables programmers to delegate the task of determining an efficient data access strategy to the WebSphere Information Integrator server. Doing so shortens the design, coding, and testing cycle as well as simplifies maintenance issues. It also minimizes the amount of application performance tuning work that a programmer might otherwise have to undertake.
  • Access to a wide variety of persistent data sources, as well as data sources that dynamically generate data (such as search engines and Web services).
  • Integration with message queuing software.
    This can be useful for tying data-driven events with other business processes in workflow-based environments.
  • Functional compensation and transparency.
    WebSphere Information Integrator can simulate functions not natively supported by a given remote data source, offering programmers additional capabilities that would otherwise be unavailable. In addition, WebSphere Information Integrator enables users to transparently exploit data source-specific functions through the use of templates.

WebSphere Information Integrator offers ready-made access to a variety of relational DBMSs, non-relational DBMSs, spreadsheets, message queues, XML documents, Web content, Web services, e-mail messages, and file systems. Another member of the WebSphere Information Integrator family, WebSphere Information Integrator Classic Federation for z/OS®, can be added (or used separately) to offer comparable access to mainframe data sources, such as VSAM, IMS, CA-IDMS, CA-Datacom, and Adabas. Partner offerings provide WebSphere Information Integrator with access to other sources as well. Finally, a new beta release of WebSphere Information Integrator offers access to popular off-the-shelf applications from SAP, PeopleSoft, and Siebel. WebSphere Information Integrator supports read access to all supported data sources and write access to relational data sources.

In addition to these EII services, WebSphere Information Integrator also supports local caching of remote data (usually for performance reasons), replication of data between two or more sources, and local persistent storage of user data.

To understand how WebSphere Information Integrator works, review these key terms and concepts. As shown in Figure 3, WebSphere Information Integrator functions as a federated database server to SDO (and other) applications. Administrators define wrappers for each type of data source they wish to access. An installation requiring access to three Oracle DBMS instances and one Teradata instance would define two wrappers: one for Oracle and one for Teradata. One or more servers are associated with each wrapper; these specify the server instances (e.g., the TCP/IP names) that host the desired data. In most production environments, administrators also define user mappings to translate a WebSphere Information Integrator user ID and password to a valid account on the remote data source. Administrators identify multiple collections of data (e.g., tables, views, files) of interest at each server; these are known as nicknames to WebSphere Information Integrator.

Figure 3. WebSphere Information Integrator federated database architecture
Fig. 3

Development cost savings, quicker time to market, and enhanced analytic capabilities are among the reasons why many firms are using WebSphere Information Integrator. Indeed, studies have shown that using WebSphere Information Integrator for Java development projects that require integrated access to disparate data can reduce coding requirements by 40 to 65 % and shorten development cycles by even greater amounts. In addition, the simple ability to augment existing data warehouses with real-time data, or provide a consolidated image of disparate data marts, is enabling firms to improve their business analysis activities.

Exploit EII in an SDO environment

Now that you're familiar with SDO, EII, and IBM's commercial implementations of them, let's explore an integrated architecture spanning these technologies.


The combined SDO and EII architecture that is outlined here adheres to the principles of a service-oriented architecture (SOA), in which business processes are implemented as distinct services capable of communicating with one another through published interfaces. SOA provides for effective software componentization, which helps promote code reuse and contributes to a more flexible IT infrastructure. The combination of SDO and EII fits into this architecture by enabling programmers to focus on the business logic necessary to support their service, delegating data access tasks to the SDO / EII layer.

IBM's JDBC data mediator service provides a critical link between SDO and IBM's EII offering, WebSphere Information Integrator. As shown in the Figure 4, this mediator works with WebSphere Information Integrator to form a virtual data access services layer for SDO applications. The mediator client establishes a connection to a WebSphere Information Integrator database and accesses disparate data transparently by issuing queries to the WebSphere Information Integrator server. In this manner, the mediator perceives a wide variety of remote data (both relational and non-relational data) as though it were in a single DB2 database. By doing so, the mediator can easily construct data graphs that are actually based on aggregated or consolidated data from multiple data sources.

Figure 4. IBM's JDBC data mediator service and WebSphere Information Integrator provides virtual data access services to SDO applications
Fig. 4

The SDO and EII architecture will enable you to:

  • Reach a wider variety of data sources immediately with SDO applications, including mainframe data sources, industry-specific data sources, and data managed by popular third party application packages, such as SAP, PeopleSoft, and Siebel
  • Reduce design, development, and maintenance complexity by employing fewer data mediator services and fewer data source connections
  • Shorten development cycles and promote rapid release schedules
  • Minimize performance tuning of data access tasks. WebSphere Information Integrator automatically analyzes the costs of various possible data access strategies and selects an efficient one for execution.
  • Automatically adjust execution strategy to accomodate changes in underlying database schemas, such as the addition of new indexes.
  • Eliminate the need for calling applications to manually aggregate, summarize or convert data (WebSphere Information Integrator handles all of the above)
  • Reduce network traffic and resource consumption. Greater amounts of data integration and filtering work can be performed by the WebSphere Information Integrator server and back-end data sources rather than within SDO applications.
  • Support SOA, promote code reuse, enhance programming productivity, and contribute to a more flexible software environment with the virtual data access services layer

Although this article focuses on the use of JDBC data mediator services and WebSphere Information Integrator, it's worth noting that WebSphere Information Integrator could potentially be coupled with other types of data mediator services, such as an EJB mediator that interfaces to entity EJBs mapped to WebSphere II nicknames. However, a full exploration of how WebSphere Information Integrator might be combined with various data mediator services is beyond the scope of this article.

Write your own code

Currently, coding your own components will provide the greatest functionality available for integrating SDO and WebSphere Information Integrator. To do so, your components will employ a small number of SDO and JDBC data mediator services objects, the latter of which will use WebSphere Information Integrator to integrate data from multiple sources and present data graphs back to calling components. In this section, we'll take you through a simple example. However, keep in mind that the current implementation is at an early release level and some aspects of the APIs described here are subject to change.

Set up your federated database environment

WebSphere Information Integrator requires no special configuration to work with WebSphere Studio, WebSphere Application Server, or SDO. Follow the standard process for installing and configuring your WebSphere Information Integrator environment, using available wizards to guide you through your work, if desired. For details, consult the online product manuals or InfoCenter, IBM Redbooks, or one of the online tutorials.

Set up your development environment

To prepare your WebSphere Studio development environment, create a project for your work. (We created a simple Java project.) Adjust the project's properties so that the Java Build Path includes all the necessary JAR and ZIP files. For WebSphere Information Integrator access, the file is included and found in the "\java" subdirectory of the WebSphere Information Integrator installation root. For SDO and JDBC data mediator services, additional .jar files are required. Figure 5 lists all the libraries you used for your project. Note that the early version of SDO included in the WebSphere Studio environment is referred to as "WDO" or Web Data Objects, which is mentioned previously.

Figure 5. External libraries used for our sample SDO applications
Fig. 5

Plan your component design

Next, you're ready to plan your component's design and begin writing your code. The basic logic you'll need to implement is fairly simple:

  • Initialize the application environment. This involves a few simple steps:
    • Establish a connection to the WebSphere Information Integrator database using standard JDBC programming techniques.
    • Create a ConnectionWrapper object.
    • Create and populate a metadata object to represent the structure of the WebSphere Information Integrator nickname, table, or view you'll be using.
    • Create a Mediator instance associated with the metadata and database connection objects previously created.
  • Obtain a data graph and populate it with the desired data from WebSphere Information Integrator.
  • Disconnect from the database.
  • Process the graph as desired.

Step 1: Initialize the application environment

Many programming tasks require some initialization or start-up activities, and this sample SDO application is no exception. Before retrieving data from WebSphere Information Integrator, you need to establish a connection to the target WebSphere Information Integrator database, create a ConnectionWrapper object for it, build an appropriate metadata object, and create a JDBC mediator instance. The subsequent sections show you how to do this.

Step 1a: Establish a database connection

Write your SDO component to connect to your WebSphere Information Integrator database just as you would write a regular JDBC application to connect to a DB2 UDB V8.1 database. Here's our code for doing so:

Listing 1. Connect to a WebSphere Information Integrator database
import java.sql.*;
. . . 

public class SDOSampleParts {
. . . 
  String dbUrl = "jdbc:db2:demo";
  String user = "myID";
  String pwd = "myPwd";
  String db2Driver = "";
  // connect to the WebSphere II database
  . . . 		
     Connection connection = DriverManager.getConnection(dbUrl, user, pwd);
  . . .  

Step 1b: Create a ConnectionWrapper

Next, create a ConnectionWrapper for this database connection. A connection wrapper is required by the JDBC data mediator service.

Listing 2. Wrap the connection for the JDBC data mediator service
. . . 
ConnectionWrapperFactory factory =

ConnectionWrapper connectionWrapper =
. . .

Step 1c: Create the metadata

The next step involves creating a metadata object and setting appropriate attributes to match the columns in the WebSphere Information Integrator table, nickname, or view that you want to use. In future releases, this metadata object may be specified through an XML file or generated by wizards, minimizing or eliminating the need to manually create the meta data. However, when working directly with the early version of SDO and its JDBC data mediator service, as you are doing here, you need to define and populate this object yourself.

This coding example defines the metadata for a "SAMPLE_PARTS" view that was created in WebSphere Information Integrator. For your reference, here's the view definition (in SQL):

Listing 3. Use SQL to create a WebSphere Information Integrator view that spans two heterogenous databases
SELECT p_partkey, p_mfgr, p_type, p_size 
FROM inf_part 
WHERE p_partkey < 10 
SELECT p_partkey, p_mfgr, p_type, p_size 
FROM ora_part 
WHERE p_partkey BETWEEN 10 AND 20

Note that this view is based on a union of two nicknames. In this environment, the nicknames mapped to an Informix® table and an Oracle table. However, they could have easily been mapped to other data sources, including non-relational data sources.

Given the view's definition, you created a metadata object consisting of four columns and designated one column as the primary key for purposes of your work. (Of course, primary keys are never defined directly against views in a commercial relational database environment. However, at least one column of any table or view must be identified to the JDBC data mediator service as the "primary key.")

Listing 4. Define the view's metadata for the JDBC data mediator service
. . . 
MetadataFactory metadataFactory = MetadataFactory.eINSTANCE;
Metadata metadata = metadataFactory.createMetadata();
Table partsView = metadata.addTable("SAMPLE_PARTS");
Column key = partsView.addIntegerColumn("P_PARTKEY");
. . .

Although not shown in the previous example, you could have defined "filter arguments" (similar to simple SQL query predicates) to restrict the rows returned for this graph. For example, you might have defined a filter argument to specify that only parts of a certain size should be included in the final data graph.

Step 1d: Create the JDBC mediator instance

A JDBC mediator object is needed to enable you to retrieve the desired data from the JDBC-enabled data source (our WebSphere Information Integrator server). Creating this mediator is simple; it merely requires that you pass in a previously defined metadata object and an active database connection (embodied by a ConnectionWrapper object).

Here's the sample code:

Listing 5. Build a mediator object for subsequent use
. . . 
MediatorFactory mFactory = MediatorFactoryImpl.soleInstance();
Mediator mediator = mFactory.createMediator(metadata, connectionWrapper);
. . .

Step 2: Obtain a DataObject

A valid mediator object enables you to retrieve the DataObject of interest with a single line of code. Based on the previous examples, the following line will rely on WebSphere Information Integrator to retrieve data in the SAMPLE_PARTS view, which spans Oracle and Informix sources:

Listing 6. Retrieve the data of interest
DataObject graph = mediator.getGraph();

Note that, at this point, you have only established a single data source connection (to our WebSphere Information Integrator server) to retrieve data spread across multiple sources. Without the use of EII technology found in WebSphere Information Integrator, you would have had to establish multiple data source connections and define multiple metadata and mediator objects (one per source). Furthermore, you would have ended up with multiple DataObjects (at least one per source), which you would either have had to pass along to a calling application for integration or integrate in your component manually. Using WebSphere Information Integrator relieved you of this added coding effort, as well as eliminated the need for you to design and code an efficient data access strategy for retrieving and integrating disparate JDBC data ourselves.

Step 3: Disconnect from the database

With the necessary data retrieved in your in-memory graph, you can exploit the disconnected nature of SDO's programming model. You have chosen to release the active database connection at this point:

Listing 7. Closing the database connection and connection wrapper
. . . 
if (connection != null) {
	connectionWrapper = null;
. . .

Note: The optimal time to close the database connection will depend on the specific business logic of your Web application.

Step 4: Process the data

At this point, you can continue to work offline with the data, processing it as desired. Here is a simple means of iterating through the graph to print out portions of its associated data.

Listing 8. Iterate through the returned data
. . . 
Iterator i = graph.getList("SAMPLE_PARTS").iterator();
while (i.hasNext()){
 	DataObject part = (DataObject);
	System.out.println(part.getInt("P_PARTKEY") + "  " + 
	  part.getString("P_MFGR") + "  " +
. . .

The SDO programming model supports retrieval of persistent data and alteration of this data while disconnected from the hosting data source. The model calls for optimistic concurrency control mechanisms (either built into data mediator services or implemented directly by programmers) to detect and resolve conflicting updates that may have occurred. Specific concurrency control mechanisms vary across commercial SDO implementations and are beyond the scope of this article.

If you had written your sample SDO application to disconnect from the database and alter the data offline, you could have later requested that these changes be applied to the database. Doing so would require you to establish a database connection and perform related work; at that point, you could have issued a statement such as this to update the database:

Listing 9. Apply changes to the database

If successful (i.e., if no conflicting updates were detected), all changes made offline to the data would be applied to the database in the context of a single transaction.

Use JavaServer Pages (JSP) generation tools

WebSphere Studio also provides an early release of tools for graphically constructing dynamic JSPs that include SDO components. How to integrate WebSphere II V8.1 (FP2 or later) services with this tooling will be explained briefly. However, greater capability is available by writing directly to the JDBC data mediator services APIs.

In general, the standard development process is unchanged when using data accessible through WebSphere Information Integrator to generate JSPs that incorporate SDO components. Nicknames appear as standard tables through the wizards.

If you're not familiar with the SDO tooling, a quick review of the development process is provided. This example creates a dynamic JSP that includes a DataList object (a collection of rows) that map to a WebSphere Information Integrator nickname. In this environment, the nickname is mapped to a collection of items posted to an external queue.

To begin, create a suitable project for your work:

  • Open the Web perspective and create a new Dynamic Web project. Specify a project name and ensure that the "Configure advanced options" box is checked. Click Next.
  • Specify a name for the EAR file and context root. Elect to use J2EE level 1.3. Click Next.
  • On the Project Features Page, check the boxes for "WDO relational database runtime" and "JSP Standard Tag Library." Click Next. (Note: The early version of SDO is often referred to as "WDO" or Web Data Objects.)
  • Choose "Use a default Page Template . . ." and select a thumbnail image from those displayed. Click Finish.

Next, add a new JSP to your project:

  • Right-click on your new project. Select New -> JSP File .
  • Provide a name for your new JSP file and verify that the "Configure advanced options" box is checked. Click Finish.

At this point, a new JSP page should be displayed and available for editing. Modify the page as follows:

  • Select Insert -> Table .
  • Position your cursor within the table and select Insert -> Data -> Relational Data List. A wizard will appear.
  • Specify a name for the Data List and click the "New . . ." button next to the Connection name field. Select "New Connection" and press Next.
  • Provide the appropriate connection information for your WebSphere Information Integrator database. This includes the database name, a valid user ID, and password. Specify DB2 UDB V8.1 for the Database Vendor Type and select an appropriate JDBC driver (we used the IBM DB2 APP DRIVER). Update the class location to point to the directory containing your file. Click Finish.
  • Select a nickname or table from the displayed list. Set the Scope to "Session" and click Next.
  • Select the columns you wish included in your datalist. If necessary, click on "Modify primary key" and ensure that at least one column is designated for the primary key. Click Finish.

With the JSP built, save your work and run it on the WebSphere 5.1 test server of your choice. The following figure shows a JSP we built using WebSphere Information Integrator to access data stored in an XML file.

Figure 6. Runtime of sample JSP created using early release SDO tools and WebSphere Information Integrator
Fig. 6

Development tips

SDO is an emerging technology currently supported at an early release level in IBM's WebSphere Studio and WebSphere Application Server products. EII technology first became available nearly a decade ago, and recent advancements have caused its use to increase considerably in the last year or so. IBM's EII offering is WebSphere Information Integrator, which you used for the work described in this article.

You can get started with a combined SDO and EII solution, by following these recommendations:

  • Work on prototypes and pilot projects rather than production applications, given that SDO support is still at an early release level.
  • Evaluate if your target projects are well suited to these technologies. In general, projects that involve read-intensive, Web-based applications that need to integrate data from disparate sources are good candidates.
  • Work with small data sets as much as possible to avoid consuming excessive amount of memory within your applications. You can limit the amount of data returned to the SDO by specifying filters in the meta data objects as described earlier.
  • Use views in WebSphere Information Integrator to represent data that needs to be joined, unioned, or otherwise correlated from multiple disparate sources. Base your SDO data graphs on these views, rather than undertaking the manual effort of retrieving required data individually from each source and then manually integrating this data into a single graph within your Java components.
  • Become familiar with diagnostic services available through SDO, WebSphere Application Server, and WebSphere Information Integrator. This will help you debug any errors you may encounter.
  • Consult reference materials included at the end of this article and participate in newsgroups to get a better understanding of these technologies and how others are using them.


SDO and EII technologies can be used together to provide Java architects with a single, object-based API to a wide variety of data sources. SDO's disconnected programming model and simple programming interface make it appealing to developers of many Web-based applications and components. EII's extensive data source support, location transparency, and global query optimization services extend and enhance data access capabilities for SDO programmers as well as reduce design and coding requirements.

This article explains how to integrate SDO and EII technologies in a service-oriented architecture. Specifically, this article covered how WebSphere Studio programmers can use JDBC data mediator services for SDO (available at an early release level) and EII technology in WebSphere Information Integrator to build a virtual data access services layer for front-end Java components.


Thank you to those who reviewed this article. Reviewers in alphabetical order: Atul Chadha, Connie Nelin, Kevin Williams, and Dan Wolfson. In addition, thank you to Kevin Williams and Brent Daniel for sharing an early draft of their article on "An Introduction to Service Data Objects".



developerWorks: Sign in

Required fields are indicated with an asterisk (*).

Need an IBM ID?
Forgot your IBM ID?

Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name

The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.


All information submitted is secure.

Dig deeper into Information management on developerWorks

Zone=Information Management, WebSphere
ArticleTitle=Using Service Data Objects with Enterprise Information Integration technology