 |
Level: Introductory
C. M. Saracco (saracco@us.ibm.com), Software Engineer, IBM
Jacques Labrie (jlabrie@us.ibm.com), Senior Software Engineer, IBM
Stephen Brodsky (sbrodsky@us.ibm.com), Senior Technical Staff Member, IBM
01 Jul 2004
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.
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
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
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
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.
Architecture
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
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 db2java.zip 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
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 com.ibm.websphere.wdo.mediator.*;
import java.sql.*;
. . .
public class SDOSampleParts {
. . .
String dbUrl = "jdbc:db2:demo";
String user = "myID";
String pwd = "myPwd";
String db2Driver = "COM.ibm.db2.jdbc.app.DB2Driver";
// connect to the WebSphere II database
. . .
Class.forName(db2Driver).newInstance();
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 =
ConnectionWrapperFactoryImpl.soleInstance();
ConnectionWrapper connectionWrapper =
factory.createConnectionWrapper(connection);
. . .
|
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
CREATE view SAMPLE_PARTS as
SELECT p_partkey, p_mfgr, p_type, p_size
FROM inf_part
WHERE p_partkey < 10
UNION
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");
partsView.beRoot();
Column key = partsView.addIntegerColumn("P_PARTKEY");
key.setNullable(false);
partsView.addStringColumn("P_MFGR");
partsView.addStringColumn("P_TYPE");
partsView.addIntegerColumn("P_SIZE");
partsView.setPrimaryKey(key);
. . .
|
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) {
connection.close();
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) i.next();
System.out.println(part.getInt("P_PARTKEY") + " " +
part.getString("P_MFGR") + " " +
part.getString("P_TYPE"));
}
. . .
|
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
mediator.applyChanges(graph);
|
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 db2java.zip 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
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.
|
Summary
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.
Acknowledgements
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".
Resources
-
Barcia, Roland. Developing JSF applications using WebSphere Studio V5.1.1 -- Part 3,
IBM WebSphere Technical Journal and IBM developerWorks, March 17, 2004.
-
Beatty, John and Stephen Brodsky, Martin Nally, Rahul Patel.
Next-Generation Data Programming: Service Data Objects, joint IBM and BEA Systems white paper, Number 2003.
-
Budinsky, Frank and David Steinberg, Ed Merks, Ray Ellersick, Timothy Grose.
Eclipse Modeling Framework, Addison Wesley Professional, ISBN 0131425420, August 2003.
- The Eclipse Modeling Framework (EMF) Overview, Eclipse Project Document, June 1, 2004.
- Haas, Laura and Eileen Lin. IBM Federated Database Technology, IBM developerWorks, March 2002.
- Saracco, C. M.
Coping with Disparate Data in Web Applications, IBM developerWorks. August 2002.
- Saracco, C. M. and Jacques Labrie, Julien Muller.
Building Portals with Enterprise Information Integration Technology, IBM developerWorks, March 2004.
- Saracco, C. M. and Susanne Englert, Ingmar Gebert.
Using WebSphere Information Integrator for J2EE Development: A Cost/Benefit Analysis,
IBM developerWorks, May 2003.
- Saracco, C. M. and T. J. Reiger.
Our Experience with Developing Entity EJBs over Disparate Data Sources,
IBM developerWorks, May 2003.
-
Specifications: Service Data Objects, WorkManager, and Timers, IBM and BEA,
IBM developerWorks, Nov. 25, 2003.
|
About the authors
|
|
|
|
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 saracco@us.ibm.com.
|
|
|
|
|
Jacques
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 validation of integration and scenarios
development of WebSphere Information Integrator with the IBM WebSphere
family of products.
|
|
|
|
|
Stephen
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 sbrodsky@us.ibm.com.
|
|
