|
![]() |
Level: Introductory Bertrand Portier (bportier@ca.ibm.com), IT Architect, IBM 28 Sep 2004 If you think the J2EE programming models and APIs force developers to spend too much time on technology-specific configuration, programming, and debugging, then this article is for you! Many Java™ developers are skeptical about how heterogeneous data can be accessed uniformly, and have been disappointed in the various programming frameworks that propose to solve the problem. In this article, Java developers Bertrand Portier and Frank Budinsky introduce you to next-generation data programming with Service Data Objects (SDO). Put simply, SDO is a framework for data application development, which includes an architecture and API. SDO does the following:
In this introduction to the SDO framework, we will try to explain the motivation behind the SDO effort and the differences between SDO and other specifications. Then, we will describe the components that make SDO. Finally, you will have a chance to see SDO in action as we describe a sample SDO application. The first question most developers will ask about Service Data Objects (SDO) is why. Isn‘t J2EE big and complex enough (and hard enough to learn) as it is? Also, other frameworks already support XML in the Java environment, don‘t they? The answer, fortunately, is one that should make most of us quite happy: SDO emerged as a means of simplifying the J2EE data programming model, thus giving J2EE developers more time to focus on the business logic of their applications. The Service Data Objects framework provides a unified framework for data application development. With SDO, you do not need to be familiar with a technology-specific API in order to access and utilize data. You need to know only one API, the SDO API, which lets you work with data from multiple data sources, including relational databases, entity EJB components, XML pages, Web services, the Java Connector Architecture, JavaServer Pages pages, and more. Note that we used the word framework. This is analogous to the Eclipse framework. Eclipse is designed so that tools can be integrated together thanks to its solid and extensible base. SDO is similar in the sense that it provides a framework to which applications can be contributed and these applications will all be consistent with the SDO model. Unlike some of the other data integration models, SDO doesn‘t stop at data abstraction. The SDO framework also incorporates a good number of J2EE patterns and best practices, making it easy to incorporate proven architecture and designs into your applications. For example, the majority of Web applications today are not (and cannot) be connected to backend systems 100 percent of the time; so SDO supports a disconnected programming model. Likewise, today‘s applications tend to be remarkably complex, comprising many layers of concern. How will data be stored? Sent? Presented to end users in a GUI framework? The SDO programming model prescribes patterns of usage that allow clean separation of each of these concerns. XML is becoming ubiquitous in distributed applications. For example, XML Schema (XSD) is used to define business rules in an application‘s data format. Also, XML itself is used to facilitate interaction: Web services use XML-based SOAP as the messaging technology. XML is a very important driver of SDO and is supported and integrated in the framework.
As we previously mentioned, SDO isn‘t the only technology that proposes to resolve the problem of data integration in distributed applications. In this section, we‘ll see how SDO stacks up against similar programming frameworks such as JDO, JAXB, and EMF. Web Data Objects, or WDO, is the name of an early release of SDO shipped in IBM WebSphere® Application Server 5.1 and IBM WebSphere Studio Application Developer 5.1.2. If you‘ve spent any time with WebSphere Studio 5.1.2, you should already be somewhat familiar with SDO, although you‘re probably accustomed to seeing it denoted as WDO, for example in library names. Forget WDO, it‘s called SDO now! JDO stands for Java Data Objects. JDO has been standardized through the Java Community Process (JCP) with 1.0 and maintenance release 1.0.1 in May 2003. A JCP expert group is being formed for version 2.0. JDO looks at data programming in the Java environment and provides a common API to access data stored in various types of data sources; for example, databases, file systems, or transaction processing systems. JDO preserves relationships between Java objects (graphs) and at the same time allows concurrent access to the data. JDO‘s goal is similar to SDO‘s in that it wants to simplify and unify Java data programming so that developers can focus on business logic instead of the underlying technology. The main difference, however, is that JDO looks at the persistence issue only (the J2EE data tier or enterprise information system (EIS) tier), whereas SDO is more general and represents data that can flow between any J2EE tier, such as between a presentation and business tier. Interestingly, SDO can be used in conjunction with JDO where JDO is a data source that SDO can access, applying the Data Transfer Object (DTO) design pattern. Similarly, SDO can be used in conjunction with entity EJB components and the Java Connector Architecture (JCA), the intent being to provide uniform data access. EMF stands for Eclipse Modeling Framework. Based on a data model defined using Java interfaces, XML Schema, or UML class diagrams, EMF will generate a unifying metamodel (called Ecore) which in conjunction with the framework can be used to create a high-quality implementation of the model. EMF provides persistence, a very efficient reflective generic object manipulation API, and a change-notification framework. EMF also includes generic reusable classes for building EMF model editors. EMF and SDO both deal with data representation. In fact, IBM‘s reference implementation of SDO, which we‘ll use later in this article, is an EMF implementation of SDO. EMF code generation was even used to create some of the SDO implementation, based on a UML model definition of SDO itself. The implementation of SDO is essentially a thin layer (facade) over EMF and is packaged and shipped as part of the EMF project. See Resources for more information on EMF. JAXB stands for Java API for XML Data Binding. JAXB 1.0 was released by the JCP in January 2003. The JCP expert group has produced an early draft for version 2.0. JAXB is about XML data binding; that is, representing XML data as Java objects in memory. As an XML binding framework for the Java language, JAXB saves you from having to parse or create XML documents yourself. (In fact, it saves you from having to deal with the XML at all.) JAXB performs the marshalling/serializing (Java to XML) and unmarshalling/deserializing (XML to Java) for you. SDO defines a Java binding framework of its own, but it goes one step further. While JAXB is only focused on a Java-to-XML binding, XML isn‘t the only kind of data being bound to SDO. As stated previously SDO provides uniform access to data of various types, only one of which is XML. SDO also offers both a static and dynamic API*, whereas JAXB only provides a static binding. * Note that the sample application for this article utilizes only dynamic SDO, although the EMF code generator also provides full support for static code generation of data objects. ADO used to stand for ActiveX Data Objects, but it is no longer true in the .NET context. ADO .NET provides uniform data access between different tiers in the .NET framework. ADO .NET and SDO share similar motivators for supporting XML and applications distributed on multiple tiers. Other than technical differences, one major difference between the two technologies is that ADO .NET is for the Microsoft .NET platform and is a proprietary technology, whereas SDO is for the Java (J2EE) platform and is being standardized through the Java Community Process.
In this section, we‘ll provide an architectural overview of SDO. We‘ll describe each of the components that make up the framework and explain how they work together. The first three components we‘ll discuss are "conceptual" features of SDO: They do not have a corresponding interface in the API. SDO clients use the SDO framework to work with data. Instead of using technology-specific APIs and frameworks, they use the SDO programming model and API. SDO clients work on SDO data graphs (see Figure 1) and do not need to know how the data they are working with is persisted or serialized. Data mediators services (DMSs) are responsible for creating a data graph from data source(s), and updating data source(s) based on changes made to a data graph. A data mediator framework is not in the scope of the SDO 1.0 specification; in other words, SDO 1.0 doesn‘t talk about specific DMSs. Examples of DMSs include: a JDBC DMS, an entity EJB DMS, an XML DMS, etc. Data sources are not restricted to back-end data sources (for example, persistence databases). A data source contains data in its own format. Only DMSs access data sources, SDO applications do not. SDO applications may only work with data objects in data graphs. Each of the following components corresponds to a Java interface in the SDO programming model. The SDO reference implementation (see Resources) provides EMF-based implementations of these interfaces. Data objects are the fundamental components of SDO. In fact, they are the service data objects found in the name of the specification itself. Data objects are the SDO representation of structured data. Data objects are generic and provide a common view of structured data built by a DMS. While a JDBC DMS, for instance, needs to know about the persistence technology (for example, relational databases) and how to configure and access it, SDO clients need not know anything about it. Data objects hold their "data" in properties (more on properties in a moment). Data objects provide convenience creation and deletion methods ( Data graphs provide a container for a tree of data objects. They are produced by the DMS for SDO clients to work with. Once modified, data graphs are passed back to the DMS for updating the data source. SDO clients can traverse a data graph and read and modify its data objects. SDO is a disconnected architecture because SDO clients are disconnected from the DMS and the data source; they only see the data graph. Furthermore, a data graph can include objects representing data from different data sources. A data graph contains a root data object, all of the root‘s associated data objects, and a change summary (more on change summaries in a moment). When being transmitted between application components (for example, between a Web service requester and provider during service invocation), to the DMS, or saved to disk, data graphs are serialized to XML. The SDO specification provides the XML Schema of this serialization. Figure 1 shows an SDO data graph. Figure 1. An SDO data graph ![]() Change summaries are contained by data graphs and are used to represent the changes that have been made to a data graph returned by the DMS. They are initially empty (when the data graph is returned to a client) and populated as the data graph is modified. Change summaries are used by the DMS at backend update time to apply the changes back to the data source. They allow DMSs to efficiently and incrementally update data sources by providing lists of the changed properties (along with their old values) and the created and deleted data objects in the data graph. Information is added to the change summary of a data graph only when the change summary‘s logging is activated. Change summaries provide methods for DMSs to turn logging on and off, as we‘ll describe in more detail in the sample application section. Properties, types, and sequences Data objects hold their contents in a series of properties. Each property has a type, which is either an attribute type such as a primitive (for example,
Enough concepts and theory! It‘s time for some hands-on practice. The good news is you can use SDO today, and for free! In this section, we provide an SDO sample application that runs on IBM‘s reference implementation of SDO, which is packaged as part of the Eclipse Modeling Framework (EMF). We‘ll first describe how to install EMF 2.0.1 (which includes SDO), and then show you how to set up the sample application provided with this article. If you already have EMF 2.0.1 installed, or if you know how to install it, skip to the next section. IBM‘s implementation of SDO 1.0 is packaged with EMF 2.0.1. You need to install EMF 2.0.1* to use SDO. You can use the eclipse update manager method, described on the EMF site, or follow the steps below. * An implementation of SDO 1.0 was also available in EMF 2.0.0. On the EMF home page, you‘ll find a collection of download links under the Quick Nav section. You want the "v2.x: EMF and SDO" download option. Make sure you read the installation requirements before you install EMF. Basically, you need to have Eclipse 3.0.1 and a Java Development Kit (JDK) 1.4 installed before you install EMF 2.0.1. Make sure you choose the EMF 2.0.1 release build. We recommend "All" as the type of package: emf-sdo-xsd-SDK-2.0.1.zip, so that you get source, runtime and docs all in one file. If you prefer, you can download the minimum package for SDO, which is labeled "EMF & SDO RT": emf-sdo-runtime-2.0.1.zip. Extract the zip file to where eclipse was extracted (files in the archive are structured as eclipse/plugins/...). To check that the EMF installation was successful, launch Eclipse and then select Help>About the Eclipse Platform. Click the Plug-in Details button. Make sure the org.eclipse.emf.* plug-ins are at the 2.0.1 level. The following six plug-ins relate to SDO:
Only the two plug-ins Installing the sample SDO application The next step is to add the SDO sample application for this article to your workspace. Follow these steps:
Next, click on the Code icon at the top or bottom of this article (or see the Download section) to get the j-sdoSample.zip. Extract it to the SDOSample directory (From within the project in Eclipse: Import... > Zip file). Make sure you keep the folder structure and overwrite existing files. The SDOSample project is now populated with the files from j-sdoSample.zip. Note: SDOSample is packaged as an Eclipse plug-in project so that you don‘t have to set the library dependencies yourself. However, the sample is just Java code, so it could also be run as a standalone application as long as the CLASSPATH includes the EMF and SDO libraries (JAR files). Your environment should now look something like the screenshot shown in Figure 2. Figure 2. Eclipse environment ![]() We‘re now ready to begin using our sample SDO application.
The example application we‘ll use for the remainder of the article is limited in terms of functionality, but it will help you understand SDO better. The application comes in two parts, which are separated into two corresponding packages: dms and client. SDO 1.0 doesn‘t specify a standard DMS API. So, for this example we‘ve designed our own DMS interface that provides two methods, as shown in Listing 1. Listing 1. The DMS interface
The client instantiates a DMS and calls its Note that for demonstration purposes we did not implement a data source component. Instead, the DMS has "hardcoded" knowledge of how to build the data graph based on the query. Figure 3 shows the employee hierarchy the DMS is using. Figure 3. The employees of the Big Boss Corporation ![]() As you can see, the virtual company behind the DMS has four employees. The company hierarchy is as follows:
To run the example application, right-click SDOClient.java, then select Run>Java application. You should see something similar to Listing 2 on your console. Listing 2. The application‘s console output
Now, let‘s see how each of the application‘s components works.
The SDO client instantiates a DMS and gets data graphs for various employees from it. Once it gets a data graph, it navigates and accesses data objects through the root object (using SDO‘s dynamic API), as shown here:
The client then calls the dynamic SDO accessor API to get information out of data objects and print it to the console, as shown here:
We‘ve seen how the client gets information out (reading), but what about writing? More specifically, how does the client modify objects? To update data objects, SDO clients typically use
Note the client doesn‘t call the logging methods. The DMS takes care of logging by calling
The data format (model) of the data graph can be considered a contract between the DMS and the client. It is what the client expects from the DMS and what the DMS knows how to build (and also to read from to update back-end data sources). If you‘re familiar with XML or Web services, you can think of the data graph model as the XML Schema (XSD) that defines your data objects. The data graphs themselves would then be analogous to XML instance documents. As a matter of fact, XML Schema is one of the ways that an SDO model can be defined. Note that data graphs and their models are always serializable to XML. In SDOClient.java, set the Listing 3. The serialized version of the data graph
For this example, the data graph is made of
SDO 1.0 doesn‘t specify a DMS API, which would include the design and creation of the data graph model itself. Designing a data graph could be the subject of another article on its own as there are many scenarios to consider when building access to a data source. For this example, we‘ll work with an employee model defined by the DMS using the dynamic EMF API. The example data graph has no model document such as XSD. The fact that data objects have been dynamically generated means no DMSs get their information from various data sources using various data access APIs (JDBC, SQL, etc.). However, once the information is retrieved from the backend (this example simply has hard-coded knowledge), the DMS uses EMF APIs (eGet, eSet), instead of the SDO ones, to build the data graph of data objects. This approach yields optimal performance but has the disadvantage of not being portable across SDO implementations. In cases where performance isn‘t a major concern, this same DMS design could be implemented using SDO APIs. In that case, the cached meta objects in the DMS class ( The code snippet below shows how the Employee model is defined, in SimpleEmployeeDataMediatorImpl.java. This isn‘t the code to build SDO objects yet; it‘s just the model of the SDO objects:
Note that we call At this point, you‘re probably thinking, "Interesting but this will give me EMF objects and not SDO data objects. What‘s the trick here?" Well, it‘s straightforward. The
At runtime the factory will create objects of type Now that we have a model of our data objects, we can build instances of
We can then "link" employees together using the "employees" reference, for example:
Once we‘ve created the data objects, we need to attach them to the data graph. We do this by calling the data graph‘s
One last thing to do before returning the data graph is to start logging changes. Before changes are going to be made to a data graph,
Another task of the DMS (as defined in the
To update backend data sources, DMSs should use the powerful features of SDO, more specifically its change summary. There are various ways to use the a data graph‘s change summary. In this example, we look at all the data objects referenced from the change summary tree and get the new data objects from there. Listing 4. DMS updating backend according to a data graph
In this example, no backend update takes place. In reality, backend updates would take place in this method. The first thing the DMS does when it gets back a data graph from the client for backend update is call
Notice that we used the standard SDO API to inspect the data graph‘s changes. We could, however, have used the EMF ChangeDescription API (instead of SDO‘s ChangeSummary). In this example, updating the value of simple attributes, the performance impact would not be significant. For other cases, such as when changing multiplicity-many properties, using the EMF API could improve performance drastically. For example, say we remove one employee from a list of a few hundred employees. In this case, the ChangeSummary only provides access to the old value, that is the old list of a few hundred employees. EMF‘s ChangeDescription interface, on the other hand, also provides more precise information, such as "remove employee at some index," which would be much more useful. Note also that in this example, there are only object changes in the change summary, no removals or additions. If you play with the SDO implementation and remove objects from the data graph, you‘ll notice elements of type objectsToAttach. This is actually the EMF ChangeDescription‘s name for object deletions. They are the data objects that were deleted and need to be attached back to the graph in case of rollback, which is EMF‘s view of the change. So to summarize,
If you set the
You can also use the Eclipse debug environment. For example, we suggest you set a breakpoint in SDOClient.java, line 110, and debug Figure 4. Looking at the data objects in debug mode ![]() This way also lets you see the change summary, as shown in Figure 5. Figure 5. Looking at the change summary in debug mode ![]() The screen captures above look complex and you may not find them useful now but you might want to come back to them when you are debugging your SDO application and looking for the contents of your data objects and change summaries.
In this article, we‘ve provided an overview of SDO and its capabilities. We‘ve showed a sample application that uses some of SDO‘s capabilities. See the SDO API documentation under the Eclipse help system for further reference. The specification is still evolving and being enhanced. For example, SDO 1.0 focused on the SDO client‘s perspective and didn‘t specify a DMS API. SDO is currently being standardized through the JCP, so watch out for announcements. Because SDO is so flexible, there will be lots of decisions you will have to make when you design your SDO application. These decisions will impact reusability and performance. So you should really think of the usage patterns and characteristics of your application data before you code.
|
联系客服