Introduction to Service Data Objects

Simply put, SDO is a data application development framework that includes an architecture and corresponding APIs. SDO enables the following actions:

Simplifies the Java EE Data programming model.

Abstract data in a service-oriented architecture (SOA).

Development of unified data applications.

Support and integration of XML.

Combine the Java EE model with best practices.

In this article on the SDO framework, we will try to explain the motivations behind SDO and the differences between SDO and other specifications, and then describe the composition of SDO and, finally, illustrate the use of SDO with a sample SDO application.

Why use SDO?

For service Data Objects (SDO), the first question most developers ask is why SDO is used. Is the EE itself not large enough, complex enough (and difficult to grasp)? Isn't there already other XML-enabled frameworks in the Java environment? Fortunately, the answer to this question is most satisfying for most of us: SDO emerged as a way to simplify the Java EE Data programming model, allowing the Java EE developer to spend more time with the application's business logic.

The Service data Object Framework provides a unified framework for data application development. With SDO, you don't need to be familiar with technology-specific APIs to access and leverage data. All you need to know is an API, the SDO API, which allows you to process data from a variety of data sources, including relational databases, entity EJB components, XML pages, Web services, Java Connector architecture, JavaServer pages Wait

Note that we use the term framework. This is the analogy of the Eclipse framework. Because the foundation of the design is strong and scalable, Eclipse can integrate tools. Similarly, SDO is a framework for applications using SDO, which are consistent on the SDO model.

Unlike some of the other data integration models, SDO does not stay on the data abstraction. The SDO framework also incorporates a number of Java EE patterns and best practices, making it easy to combine proven architecture and design with applications. For example, most WEB applications today have absolutely no (or no) connections to back-end systems, so SDO supports a disconnected programming model. Similarly, today's applications are often very complex and contain many layers. How do I store data, how do I send data, and how do I make them available to end users in a GUI framework? The application patterns provided by the SDO programming model can clearly divide the different problems.

XML is becoming increasingly popular in distributed applications. For example, an XML Schema (XSD) is used to define business rules in the application data format. XML itself can also be used to improve interactivity: Web services use xml-based SOAP as the message format. XML is an important reason to push SDO, and the SDO framework supports and integrates XML.

Comparison of various technologies

As mentioned earlier, SDO is not the only technology that addresses the problem of data integration in distributed applications. The following will discuss the pros and cons of SDO and similar programming frameworks JDO, JAXB, and EMF, respectively.

SDO and Wdo

Web Data Objects (or Wdo) are the earlier versions of SDO released by IBM Websphere®application Server 5.1 and IBM WebSphere Studio application Developer 5.1.2 Name. If you have used WebSphere Studio 5.1.2, you may already have some understanding of SDO, although you may be accustomed to seeing it marked as Wdo, such as in the name of the database. Forget Wdo, its name is sdo!.

SDO and JDO

JDO represents the Java data Object (Java). JDO has standardized the 1.0 version through the Java Community process (JCP), and the maintenance edition 1.0.1 was launched in May 2003, and the JCP Expert Group has now been set up for version 2.0. JDO provides a common API for data programming in a Java environment for accessing data stored in different data sources, such as databases, file systems, or transaction processing systems. JDO maintains the relationship between Java objects (graphs), while allowing concurrent access to data.

JDO wants to simplify and unify Java data programming so that developers can focus on the business logic rather than the underlying technology, and in this sense the goal is the same as SDO. The main difference, however, is that JDO considers persistence issues only (the Java data tier or the Enterprise Information System (EIS) layer), while SDO is more general, focusing on representations of data flows between different Java-ee tiers, such as the presentation layer and the business layer.

Interestingly, SDO can be used in conjunction with JDO, which is accessed by JDO as a data source and SDO, which is the specific application of the data Transfer object (data transfer objects, DTO) design pattern. Similarly, SDO can be used in conjunction with both the Entity EJB component and the Java Connector Architecture (Java Connector Architecture, JCA) to provide uniform data access.

SDO and EMF

EMF represents the Eclipse Modeling Framework (Eclipse modeling frameworks). EMF generates a unified Metamodel (called Ecore) based on a data model defined using Java interfaces, XML schemas, or UML class diagrams, which can be combined with a framework to create a high-quality model implementation. EMF provides persistence, a valid reflection generic object manipulation API, and a change notification framework. EMF also includes generic reuse classes that are used to build EMF model editors.

Both EMF and SDO can handle data representations. In fact, IBM's SDO reference implementation is an EMF implementation of SDO, which we'll use later. You can also create some parts of the SDO implementation based on the UML model definition or SDO itself, using EMF code generation. The SDO implementation is essentially a small layer (aspect) of the EMF that is packaged and provided as part of an EMF project. For more information on EMF, see Resources.